Azure Developer Lifecycle for .NET Developers

[CamSoper]

We are undertaking a project to develop content (originally an e-book, still might be, or it might be an interactive thing) to set the minimum bar for a complete .NET development lifecycle on Azure. This issue is to track the progress of the content and provide a channel for discussion.

We're looking for feedback as we undertake this. We invite the community to comment and make revisions as we go! 🙂

Please review the working outline. Work will be done in the azure-lifecycle branch.

[CamSoper]

My own comments (please discuss):

Tools

• How much emphasis should we be putting on VS2015? VS2017 doesn't require any downloads, but VS2015 does.

Web App

• I'm thinking an MVC app. It should be familiar to most ASP.NET devs. Razor Pages would also be a good simple demo. I think we should stay away from SPAs with Web APIs though because that introduces a little more complexity (SPA framework, etc.)
• We've done To-Do apps to death. I need more ideas here.
• Which Azure service should it use? SQL Database seems like a good fit due to familiarity for .NET devs. Could use LocalDB for dev and publish to SQL Database on Azure. HOWEVER - Cosmos DB has the NoSQL attractiveness and the "cool" factor of being a REST-based cloud data store. Also, I really feel like we should be stressing PaaS services like Cosmos to get devs in the mindset of cloud-based services that aren't IIS or SQL. IIS and SQL are familiar, but there are so many PaaS services in Azure that introduce new ways of doing things.
• For authentication, I really want to use B2C here. I feel like that's how ASP.NET devs should be doing most public-facing auth. However, I'm afraid of getting too far into the weeds on B2C in this project. I’m actually afraid of this topic altogether, because if we DO use ASP.NET Identity, then we’ve got a dependency on a SQL database, which may complicate things.

Continuous Integration

• Should this be earlier in the outline? I mean, in a green field project we'd do this first, but how many apps come into the cloud like that? Maybe call that out here?

Best Practices

• I don’t want to get into the weeds here, but these things seem like things that we should at least mention.

[scottaddie]

How much emphasis should we be putting on VS2015? VS2017 doesn't require any downloads, but VS2015 does.

Let's focus on VS 2017. We aren't resourced to write docs for the laggards.

I'm thinking an MVC app. It should be familiar to most ASP.NET devs. Razor Pages would also be a good simple demo. I think we should stay away from SPAs with Web APIs though because that introduces a little more complexity (SPA framework, etc.)

The product unit has positioned Razor Pages as the recommendation for building ASP.NET Core 2.x web apps. Let's stick with that.

Which Azure service should it use? SQL Database seems like a good fit due to familiarity for .NET devs. Could use LocalDB for dev and publish to SQL Database on Azure. HOWEVER - Cosmos DB has the NoSQL attractiveness and the "cool" factor of being a REST-based cloud data store. Also, I really feel like we should be stressing PaaS services like Cosmos to get devs in the mindset of cloud-based services that aren't IIS or SQL. IIS and SQL are familiar, but there are so many PaaS services in Azure that introduce new ways of doing things.

I think Cosmos DB would be great! The CDAs have been pushing it hard. This content could serve as yet another medium for promoting its capabilities.

Should this be earlier in the outline? I mean, in a green field project we'd do this first, but how many apps come into the cloud like that? Maybe call that out here?

I agree that CI should be discussed early on. A properly built build definition in VSTS goes a very long way in terms of catching problems early. As part of this section, I'd like to see mention of how to run unit tests in the build definition and display meaningful test results (e.g., code coverage) on the project dashboard.

[CamSoper]

Comments from @CESARDELATORRE provided by email, copied here (with permission) for tracking:

• Simplify the following (App development and deployment to Azure) as we have already significant guidance about it: 3. Build a Web App that consumes an Azure service
  4. Deploying the app to App Service and monitoring

• More details on DevOps, CI/CD, Monitoring, Logging, app Analysis, etc. So, further focus on: 5. SPECIFIC CHAPTER: DevOps and CI/CD toolchain
  NEW SPECIFIC CHAPTER: Specific chapter on Monitoring, Analytics, Logging, Crashes and Debugging

[erickson-doug]

devops (with or w/o vsts) should be integral to most if not all scenarios, maybe with callouts as to "why do this"

[jawn]

Talking about VS Code in addition to VS 2017 makes things usable on all platforms. But it's extra work.

Who is your audience?

[CamSoper]

@jawn - The assumption is experienced ASP.NET developers (200-300 level) with no cloud experience. I think we're going to assume VS2017 since that'll include most ASP.NET devs, but I do hear you loud and clear on the cross-platform.

[seesharprun]

You can use the Cosmos emulator for local development.

Since this project is greenfield, it would be ideal to use the SQL API for Cosmos. It’s .NET SDK is pretty mature and integrated well with IQueryable<>. You also get the benefit that the API doesn’t change much between .NET and .NET Core. There’s learning paths already available for devs who want to go down that rabbit hole.

The other Cosmos APIs require a bit of existing knowledge in Mongo, Cassandra or Tables.

[aaronralls]

You should do a MVC app that relies on a separate API done in .NET Core 2.x

[samclintock]

Hi @CamSoper, great idea on the project.

Have you considered Azure Functions at all? I totally understand that an MVC app would be useful to demonstrate deploying and hosting on an Azure App Service, but the majority of the development would still be in Visual Studio, and similar as a deploy to IIS. If a function were to be used, for a simple API for example, you could also demonstrate the scalability of Azure.

Perhaps a very basic SPA being used for the UI and an API endpoint built as a function that interacted with data in CosmosDB?

[tidyui]

VS2017 should probably be targeted even though I personally think Visual Studio Code and DotNet CLI is a must for any .NET core tutorial. Let us know if you need help complementing your material with this.

For deployment CI is good with a couple of options, like:

• TFS with VS-online build server
• GitHub with AppVeyor

As far as technology goes most already experienced.NET developers will probably use MVC together with an App Service as this is the most common technique. Highlight the differences between the frameworks.

Also, if the app should receive and upload media files, consider using Azure Blob Storage together with Azure CDN for delivery, you can “borrow” my code as reference :)

https://github.com/piranhacms/piranha.core

Like mentioned earlier an example of Azure Functions would also be sweet.

For local dev database, use SQLite, LocalDb isn’t cross-platform and will limit your audience.

For client side asset compilation, use a mixture of WebCompiler for VS and gulp (or equal) for non windows setups. Again, you can look at my repo for reference.

Also some simple unit test will probably be good, even better if integrated with an online service like OpenCover for code coverage (again, take a look at how I’ve set this up).

Regards!

[rafaelbarrelo]

• AppService vs ContainerService - How to choose?
• HTTPs with Let's Encrypt

[jaxidian]

I'd generally like the focus to be less on development itself and more on integration challenges. As frameworks advance, more and more of our jobs are focused on integrating systems rather than writing code. And this is also where we can go deep down the wrong path and spin our wheels for quite a while.

1. Consider building multiple applications with different lifecycles. It's easy to manage a single application with static dependencies. But when you have two applications changing and deploying independent of one another, the challenges are very different and more akin to what we experience in the real world.
2. Make operations facilitation a first-class concern. Most efforts like this end up just having a footnote saying something to the effect of "Just throw Application Insights at it and you have everything you need", but we know better than that. What about administrative dashboards with feature flag management to put systems into read-only mode during high-risk maintenance windows? What about intentional throttling of background processing because of unexpected DB performance issues? AI is good for visualizing errors and performance metrics, but you also sometimes have to actually do things as well, and often times they're the same things over and over that you want to have tools prepared for.
3. Include an async background processing component to help showcase how a real-time responsive web app can also integrate with slow/legacy/background processing. The implementation of the background jobs themselves aren't terribly important but you could use some queues and functions with random sleeps to simulate slow jobs, or you could really do anything for this.
4. Include Power BI Embedded. This is an incredibly powerful tool for those who want to embed a dashboard/visualization component into the web application, and sadly, Power BI Embedded is a fairly neglected offering. Don't get too deep in the actual development of the dashboards, just perform the integration and handle the deployments with your CI.

I have a feeling this increases the scope of what you're intending to do significantly, but consider if there's some way to handle these types of integration concerns, even if in very different ways than I've suggested here. I can't tell you the last time I built a web app where it was alone on an island and just consumed a PaaS service in a clean manner. Highlighting that simple scenario misses an opportunity to address the challenges that most people struggle with. I'm not saying that's necessarily your plan but I just wanted to make sure this was considered. Perhaps you've already considered it and I'm just wasting a few kB of Github's diskspace, and that's fine! :-)

[paulio]

My immediate thoughts would be to add (in no order);

• Deployment slots, bring manual/uat testing into the cycle
• The difference between config settings from the code to changing configs settings on the server. I.e. important to show that admins often have the final control over the settings
• logging strategy, esp. concerning scale out/up, correlation ids

[tidyui]

Good call @paulio +1 on deployment slots

[seesharprun]

If you talk about deployment slots, we should also talk about:

• Sticky settings (test database always pointing at test slot)
• Testing in production (implementing simple A/B testing using a UI change to the web application)

[CamSoper]

This is great feedback, everyone! Thanks so much!

We are trying to keep the scope narrow, but how narrow is still a question that's TBD. We've definitely talked a lot about a "things you might have done differently" chapter, or perhaps a sequel.

[Rick-Anderson]

@aaronralls

You should do a MVC app that relies on a separate API done in .NET Core 2.x

We're featuring Razor Pages apps in new content.

@jaxidian

I'd generally like the focus to be less on development itself and more on integration challenges

+10

[CamSoper]

@Rick-Anderson I initially said MVC because of my own comfort with it, but @scottaddie and I decided yesterday that in order to pass the "Rick" test, we'd need to do Razor Pages. 😉

[tidyui]

Out of curiosity @CamSoper, what’s the official line on Razor Pages. To me it’s just an extended version of WebPages, which always felt like a sneak version of MVC designed to lure PHP developers over to .NET :) I always liked its simplicity and actually designed the initial version of Piranha CMS for it, BUT as time went by I had to convert my framework to MVC as no one wanted to use WebPages.

What will be different with Razor Pages and why should developers choose it instead of MVC?

[Rick-Anderson]

@tidyui

Out of curiosity @CamSoper, what’s the official line on Razor Pages.

We recommend RP for new app dev. Large teams may still prefer MVC.

To me it’s just an extended version of WebPages,

I take it you haven't done much development with RP. It's much more like MVC than WebPages. After porting ASP.NET Core MVC with EF Core to RP, I started to see the advantages. No more viewdata, view models built in. Much easier to find/update code. I find it has a much more natural organization.

[rloutlaw]

I'm just going to echo a few other points here for emphasis:

• Build a sub-MVP grade IoT-ish dashboard, image gallery, or location/review (yelp-ish) style application. These are tougher to develop than a todo-style application but this effort is deeper than just traditional tech docs tutorial work and needs more moving parts to be worth reading vs. traditional tutorials.
• You want two applications involved-one would be the main application with the view and such , the other should really be running in Azure Functions or deployed as a web API in App Service (prefer functions here)
• I'd spent the majority of the content discussing integration between the application and its cloud-related elements and less time on the development of the applications itself. Most of the code going to be more or less familiar, the Azure element will not be.
• CI testing/deployment, logging and monitoring should be in the content and used to verify that all the cloud services integration in the app is working-bring these things into the inner loop experience.
• I'm ambivalent on the services used in the application but do consider meeting your user base where they are so they can rely on their existing knowledge as much as possible. This will make success with the parts of the stack they aren't familiar with more likely.

[CamSoper]

All, I've updated the outline using your feedback and written an introduction to set the tone and scope of the guide. Feedback appreciated! Looking especially for @erickson-doug @rloutlaw @scottaddie and @wadepickett