Building and auto-deploying an ASP.NET Core application - Part 7 - Improving your build and release processes

Published 3 years ago

This is the last part in a series of 7 articles showing you how to build a database-driven ASP.NET Core 5.0 app and deploy it to a remote web server using continuous integration and deployment with GitHub and Azure DevOps. In this final part I'll touch on two improvements you can make to the process you've seen in the earlier articles. In particular, I'll show you how to set up your own build agent to build your software on a custom server rather than on a standard Azure DevOps agent to speed up the build process. I'll also show you how you can minimize downtime when deploying your site to a Microsoft Azure App Service by using deployment slots. This article closes with a quick summary of all I've discussed in this series of articles.

Building and auto-deploying an ASP.NET Core application - Part 6 - Setting up a CD pipeline - Deploying to an Azure App Service

Published 3 years ago

In the previous article you saw how to take your compiled application and deploy it to a web server running IIS. This is a convenient scenario when you own or manage the remote server completely as you need to install a release agent on it. You also saw how to use a SQL task in the release pipeline to automatically apply the EF migrations to your database on release.

In this article you see how to do the same, but with an Azure App Service and an Azure SQL database instead. An App Service is a fully managed web hosting service for running web sites, mobile back ends, and RESTful APIs. It allows you to run web sites on the Internet without the need to manage a complete server yourself. Azure SQL is Microsoft's cloud version of their popular database system SQL Server.

App services and SQL Azure are popular choices for running a data-driven web site in Microsoft's cloud solution. I use them a lot for many of my customers' solutions and therefore thought it made sense to demonstrate and discuss them here as well. In this article I'll show you how to create a release pipeline in Azure DevOps that deploys your application to an Azure App Service. In addition, you see how to create and configure an Azure SQL server and database and how to automatically update the database's schema during the release with changes coming from your EF migrations.

Building and auto-deploying an ASP.NET Core application - Part 5 - Setting up a CD pipeline - Deploying with web deploy to a VM

Published 3 years ago

In the previous article you saw how to create a build pipeline in Azure DevOps to automatically build and test your software every time changes are submitted to your GitHub repository.

In this article and the next you see how to complement this process with an additional pipeline that automatically releases your software to a remote server so it can be accessed by your end users. In this article you see how to deploy your site site to a server running IIS, such as a virtual machine in the cloud or a (virtual or physical) machine in your own network. The next article then shows how to do the same but for an Azure App Service, an HTTP-based service for hosting web applications, REST APIs, and mobile back ends in the Microsoft Azure cloud.

Note: if you like to purchase the entire series now and not wait for the remaining parts to come online, check out this blog post that explains how you can purchase it for only $8.

Building and auto-deploying an ASP.NET Core application - Part 4 - Setting up a CI pipeline in Azure DevOps to build and test your code

Published 3 years ago

In this article I finally get to showing you how to create pipelines in Azure DevOps. I've been mentioning this for a few articles now but there was some groundwork I had to take care of first. In this article, the 4th in a series of 7, I'll show you the following:

• What YAML is and why you need it
• How to build a pipeline in Azure DevOps to build your source code every time you do a check in on GitHub.
• How to modify your build to save the results so they can be deployed to a remote server at a later stage
• How to add a unit test project to your solution and configure the build to execute your tests
• How to create EF Migration scripts which can be run against the database during the release

Note: if you like to purchase the entire series now and not wait for the remaining parts to come online, check out this blog post that explains how you can purchase it for only $8.

Building and auto-deploying an ASP.NET Core application - Part 3 - Dealing with change

Published 3 years ago

In the previous article in this series I showed how to set up the initial web application and add Entity Framework as the database persistence framework. This provides a good starting point for the application. As you'll be expanding the application you need a good way to manage code and database schema changes. In this article you'll see how to leverage Git, GitHub and EF migrations to manage code changes. In the next article in the series I'll then finally show you how to set up a CI pipeline followed by a CD pipeline in a later article.

Note: if you like to purchase the entire series now and not wait for the remaining parts to come online, check out this blog post that explains how you can purchase it for only $8.

Building and auto-deploying an ASP.NET Core application - Part 2 - Creating the web application

Published 3 years ago

This is part 2 in a series of 7 articles showing you how to build a database-driven ASP.NET Core 5.0 app and deploy it to a remote web server using continuous integration and deployment with GitHub and Azure DevOps. In this part I'll show you how to set up the basic application, add a model that uses Entity Framework Core 5.0 to persist data to the database and how to create to the initial database.

Note: if you like to purchase the entire series now and not wait for the remaining parts to come online, check out this blog post that explains how you can purchase it for only $8.

Building and auto-deploying an ASP.NET Core application - Part 1 - Introduction

Published 3 years ago

I have been programming for many years and over those years, I have seen the development landscape change quite a lot. Things have become both simpler and more complex at the same time. For example, setting up a web server on Windows to run a Classic ASP site with COM+ components was pretty complicated back in the days. Setting up an Azure app service today to do more or less the same as that old web server did takes just a couple of clicks in the Azure portal. At the same time, things have become more complicated because possibilities, demands and requirements have changed. For example, when I started programming, distributed source control usually meant a shared network drive where everyone would write to and that was occasionally backed up ;-) But nowadays, we have powerful source control systems like Git that allow for more feature-rich management of your source code including history, branching and a lot more. And combined with powerful online platforms like Azure DevOps and GitHub, you have all the tools you need at your fingertips.

Introducing a new article series: Building and auto-deploying an ASP.NET Core application with EF Core 5.0

Published 3 years ago

Over the past couple of weeks I have been working on a new article series on building and auto-deploying an ASP.NET Core application using ASP.NET Core 5.0, Entity Framework Core 5.0, Git, GitHub and Azure DevOps. Just this week I wrapped up the last article and the series is now done! I've published the first article in the series today, and the remaining 6 parts will come online in the coming weeks.

Improving your ASP.NET Core site's e-mailing capabilities

Published 3 years ago

Many websites depend heavily on e-mail: they send account confirmation e-mails, password reset e-mails, order confirmations, back-in-stock notifications and much more. Despite its importance, I often see that sending e-mail is an overlooked area when writing well maintainable and stable code. It's also often overlooked when monitoring sites and lots of code I have seen just assumes the mail server is up and running. But problems will occur; mail servers will go down, passwords do expire or get changed without updating the web site and more.

In a preceding article you saw how to monitor your site's SMTP server using an ASP.NET Core health check. While it's great to be notified when your SMTP server is unavailable, it would be even better if your site has an alternative way to deliver the messages when the primary SMTP is not available.

In this article, I'll show you a couple of ways to improve the way you send e-mails from your ASP.NET Core applications. In particular, I'll discuss:

• Hiding send functionality behind an interface
• Providing multiple concrete implementations to send e-mails in different ways and configure the best one at runtime
• Implementing a fallback solution for cases where your primary mail server is not available
• How to use MailKit to replace the built-in SmtpClient which is now considered obsolete by Microsoft
• How to use the SendGrid API to send e-mails from your application

You'll find the full code for the article as a download at the end of this article, as well as in the Github repository for this article.

Using Standard Health Checks and Building your Own in ASP.NET Core

Published 4 years ago

Being able to monitor your ASP.NET Core web applications and APIs and detect any issues early on is crucial in ensuring your sites are up and running and in a healthy state. In previous articles I talked about creating a custom health check solution for ASP.NET Framework applications and implementing ASP.NET Core health checks with standard functionality. In this article I'll show you how to add and configure some existing, open-source health checks to monitor an SMTP server and the web server's disk space (these are just examples; there are many more health checks available that you can plug in to your own web site). And if the standard health checks aren't sufficient, you can build your own; something you'll see how to do in the second part of this article.