Continuous Delivery with Azure DevOpsDevelopment
This article will set up a basic .Net Core Web API project deployed to an Azure App Service with Continuous Delivery using Azure DevOps.
We’ll get started by creating a new App service in Azure that will host the Web API. In the Azure Portal, create a new Web App in App Services.
Now head over to Azure DevOps (formerly known as Visual Studio Team Services, or VSTS) and create a new project. Give it a name and description and click Create. This will start a new project with an empty Git repository.
Note with naming the project, if you have spaces in the project name, make sure you rename the default repo to remove spaces. Spaces in the repo name can cause issues with committing changes outside of Visual Studio.
Add some code!
Open Visual Studio, and in Team Explorer, connect to the new repository (Team -> Manage Connections, then Connect to a project). This will clone the repo to the location you specify.
If you have an existing project, you can copy the project files in to the new repo or create a new project. I’ve created a new .NET Core project in the cloned repo directory. Make sure the project compiles and runs without any errors. Once you have your project set up, check in your changes to the Git repository using either Visual Studio’s Team Explorer tab or using Git command shell.
Set up the Build pipeline
At this point we have an empty App Service in Azure, and a .Net Core project checked in to the DevOps project repository. Now we can set up the Build and Release pipelines.
In DevOps, go to Pipelines -> Builds -> New pipeline. It should pre-select the default repo for the project with the master branch. You can leave the selected defaults and click continue. On the Choose a template screen, search for ‘.net core’ and select the ASP .NET Core template by hovering over the template and clicking Apply:
Leave the default settings in the Tasks tab but take note of the value of Artifact name field under the Publish Artifact step. By default, it should be drop. Click the Triggers tab. Click the checkbox Enable continuous integration and make sure the Type drop down is set to Include, and the Branch specification is set to master.
These setting will trigger the build when a change is detected in the master branch of the repository. Click the Save & queue button and select Save.
Keep the default value of the Select folder field and click Save.
Set up the release pipeline
Go to Pipelines -> Releases -> New pipeline and select Azure App Service deployment as the template, which will give you this:
In the Artifacts section, click Add and artifact. Leave the Build option selected and select the build pipeline you created in the previous step in the Source (build pipeline) drop down. Select Latest from the Default version drop down and enter drop in the Source alias field. Click Add. Click the lightning bolt in the new artifact to enable continuous deployments:
Click the down arrow next to the Add button under Build branch filters, and select Build Definition’s default branch. This will made sure the release is only triggered for a build of the repo’s master branch.
Click the Tasks tab then click on Stage 1. Select your Azure subscription and Authorize the connection. Leave App type as Web App and select the App service that you set up at the beginning of this article from the App service name drop down.
Hover your mouse over the release pipeline name and click to edit.
Click the Save button and keep the default value of the Folder field and click OK.
Commit changes to the project to trigger a deployment
Back in Visual Studio, make any changes to the project and check in your changes to the Git repository using either Visual Studio’s Team Explorer tab or using Git command shell.
DevOps should now detect the change to the master branch of the repo and start the build pipeline. In DevOps, navigate to Pipelines -> Builds and you should see the new build has started.
You can click on the build in progress and view the output of the build tasks. On a successful build, it will create the release artifacts and trigger the release pipeline. You should also receive an email notification that the build has completed.
Navigate to Builds -> Releases and you should see the release that has been triggered from the successful build.
Once the release has successfully completed, view your app in the browser and you should see your app running!
Now you can continue development and any time you check in changes to the master branch of the repo, a new build and deployment will be triggered. If you check in code that fails to compile or run without errors, the build pipeline will fail, and nothing will be deployed.
It’s also a good idea to set up the repo to prevent direct code check-ins to the master branch and set up a development branch with pull-request rules to merge back in to master. You can also set up a build pipeline to run from any branch in the repo, and not just the master branch.