In previous article, we have seen how to create an organization, a project and a repository for the project. The repository is empty when we created it. We also have discussed how to add code and how to invite team members to contribute to the repository.

In this article, let’s see how can we enable continuous integration and continuous delivery for a solution. For following the steps, you can use the application from my GitHub repository.

this application has .NET Core 3 web application, which uses entity framework core (code first) to interact with database. In this article, let’s see how can we configure CI for this application.

Import repository from GitHub

You can import the code from GitHub repository into your Azure DevOps repository. If you click on repository name shown on top, you will be shown option to import repository.

Then in the below popup, you can specify the

• Repository type, Git or TFVC
• Clone URL, the URL of GitHub Repository (or any Git repository you want to clone)
• Name, the name of repository.

Then you can click on Import button. This will import the repository in Azure DevOps.

Let’s Begin

Now, if you go to Pipelines option, you will be able to see a Create Pipeline button as shown in below snapshot.

When you click on Create Pipeline, you will be shown next screen, where you will be asked to select the place where your code is located.

You can create a build pipeline in Azure DevOps and your code can be present in BitBucket or GitHub.

For this demo, our source code is located in Azure Repos. But do not select it yet.

YAML vs Classic Editor

Before going further, we need to know one more thing – YAML vs Classic Editor.

YAML is the new way of specifying the build definition. You can specify the build definition in a file and then you can maintain that file somewhere. It is very handy if you have very big team and build definitions are changing often.

The classic editor provides you user interface to define the CI. For this article, we will select the classic editor. I will also show you how can you export the build definition in the form of YAML, in case you want to maintain the YAML file too.

So, let’s click on Use Classic Editor link highlighted in below snapshot.

Build Definition Wizard

This wizard is shown if you select the classic editor option.

You are asked to select the source code location and other details. Select as shown in snapshot and click on Continue.

On next screen, you will be asked to select a build template. Alternatively you can also start with a blank template.

As this is our first attempt, it makes sense to use a pre defined template. We will select ASP .NET Core template for our application. Then click on Apply.

Build Definition

This will bring below screen. You can see different steps which are already configured for you. The build will get source code, restore nuget packages, build your application and run all unit tests too.

The last step Publish Artifact is to publish a ZIP file, to a location. The deployment pipeline then can take this artifact and deploy it to the target location. The deployment pipeline is not discussed in this article.

There are multiple tabs on the screen. If you go to Variables tab, then you can configure the build configurations and other build variables if you want. For this demo, let’s keep them default.

In Triggers tab, you can click on Enable continuous integration checkbox. This checkbox means, whenever there is a merge to your branch (which you selected under branch filters below), this build definition will try to build the branch.

Then you can click on Save & Queue button. This will bring the dialog where you can specify the Agent details. I prefer windows-2019 as Agent, but there are numerous options available. You can go for linux or MacOS based agent too.

You also need to add a Save comment where you can describe the changes you have made.

Once you click on Save and run on this dialog, a new build will be triggered

And that’s how you configure the CI for your repository. The artifacts (zip packages) generated by this CI build would be used by Release pipeline to deploy the application.

Create Database Package

The build you created will create only one ZIP file for your web application so release pipeline will be able to deploy only web application.

But we also want to deploy the EF Core Code First database using CD pipeline. So in order to do that, we will have to add a step in build to create a package for database deployment. Let’s see how can we do it.

Generate Migrations

Let’s add a command line task to build by using a plus (+) button near the Agent Job 1. Then you will be able to see a window as shown below.

Rename the task to Build EF Migrations. In Script text box, add below two commands separated by new line character (ENTER key). Please refer my previous blog to know more about these commands.

dotnet tool install –global dotnet-ef –version 3.1.0

dotnet ef migrations script –startup-project $(Build.SourcesDirectory)\MyFitnessLog -o $(build.artifactstagingdirectory)\migrations\scripts.sql -i

Publish Migration Scripts

Now, add a Publish build artifacts step in the build. Rename it to Publish EF Migrations as shown in below snapshot.

Modify Path to Publish and append /migrations to existing path.

Also, Modify the artifact name to be Migrations.

Finally, you also have added steps to package the EF Core Code First migration scripts. I hope you enjoyed this article. Let me know your thoughts.