Chapter Summary

In this chapter we bring together what we’ve done so far: build activity, source control, and unit testing and frame it within the context of Continuous Integration/Continuous Delivery (CI/CD).

What Is CI/CD?

To talk about CI/CD is to talk about a pipeline of work” or, if you prefer another analogy: a production line, where a product (in this instance working software) is taken from is raw form (code¹) and gradually transformed into working software that’s usable by the end users.

Clearly, this process will include a number of steps, most (if not all) we will want to automate.

It’s essentially about the faster realization of business value and is a central foundational idea of agile software development. (Fret not, I’m not going to bang that drum too much.)

CI/CD or CI/CD?

Don’t worry, the heading is not a typo (we’ll come on to that in a minute).

CI is easy; that stands for Continuous Integration. CI is the process of taking any code changes from one or more developers working on the same piece of software and merging those changes back into the main code “branch” by building and testing that code. As the name would suggest, this process is continuous, triggered usually when developers “check-in” code changes to the code repository (as you have already been doing with Git/GitHub).

The whole point of CI is to ensure that the main (or master) code branch remains healthy throughout the build activity and that any new changes introduced by the multiple developers working on the code don’t conflict and break the build.

CD can be a little bit more confusing. Why? We’ll you’ll hear people using both the following terms in reference to CD: Continuous Delivery and Continuous Deployment.

What’s the Difference?

Well, if you think of Continuous Delivery as an extension of Continuous Integration, it’s the process of automating the release process. It ensures that you can deploy software changes frequently and at the press of a button. Continuous Delivery stops just short of automatically pushing changes into production though; that’s where Continuous Deployment comes in.

Continuous Deployment goes further than Continuous Delivery, in that code changes will make their way through to production without any human intervention (assuming there are no failures in the CI/CD pipeline, e.g., failing tests).

The Pipeline

Google “CI/CD pipeline,” and you will come up with a multitude of examples; I, however, like this one.

You may also see it depicted as a “loop,” which kind of breaks the pipeline concept but is nonetheless useful when it comes to understanding the continuous cycle of DevOps activity.

Coming back to the whole point of this chapter (which if you haven’t forgotten is to detail how to use Azure DevOps), we are going to focus on the following elements of the pipeline.

Technology in Context

Referring to our pipeline, in terms of our technology overlay, this is what we will be working with to build a CI/CD pipeline.

Indeed, Azure DevOps comes with its own “code repository” feature (as mentioned in Figure 12-5), which means we could do away with GitHub.

So, our mix could look like the following.

Or if you wanted to take Microsoft technologies out of the picture, see Figure 12-7.

Going further, you can even break down the Build ➤ Test ➤ Release ➤ Deploy, etc. components into specific technologies. I’m not going to do that here.

The takeaway points I wanted to make were

1. 1.

   The relevant sequencing of technologies in our example.

    
2. 2.

   Make sure you understand the importance of the code repository (GitHub) as the start point.

    
3. 3.

   Be aware of the almost limitless choice of technology.

    

OK, enough theory; let’s build our pipeline!

Create a Build Pipeline

If you’ve not done so already, go to the Azure DevOPs site, https://dev.azure.com, and sign up for a free account (be careful that you actually login to Azure DevOps and not Azure). The landing screen should look something like this (minus the projects I have).

Once you have signed in/signed up, click “New Project.”

You can call it anything you like, so let’s keep the theme going and call it Command API Pipeline.

Once you’re happy, click “Create”; this will create your project and take you into the landing page.

This first thing that it asks us is: “Where is your code?”

Well, where do you think?

Yeah – that’s right – in GitHub!

Be careful to select GitHub, as opposed to GitHub Enterprise Server (which as the description states is the on-premise version of GitHub).

Supply your GitHub account details and sign in. Once you’ve given Azure DevOps permission to connect to GitHub, you’ll be presented with all your repositories.

Pick your repository (my example repository is shown in Figure 12-15); once you click it, Azure DevOps will go off and analyze it to suggest some common pipeline templates; you’ll see something like that in Figure 12-16.

All this step will do is preconfigure the azure-pipelines.yml file for you (more on this next, but it’s basically the instructions for our CI/CD pipeline). We are going to create our azure-pipelines.yml file from the ground up so it doesn’t really matter which one you choose as we’ll be overwriting it. Anyway, select an option and continue.

Irrespective of which template you pick you’ll get a default azure-pipelines.yml file, take a quick look (chances are yours will look different).

Select the entire contents, and press delete; your file should now be completely empty.

We are now going to add the first step to our file, which is simply to build our API Project. Before we do that, please read the warning below on formatting YAML files!

Your YAML file should look like this.

We’re now ready to Click Save and run.

You’ll then be presented with the following.

This is asking you where you want to store the azure-pipelines.yml file; in this case we want to add it directly to our GitHub repo (remember this selection though as it comes back later!), so select this option and click Save and run.

An “agent” is then assigned to execute the pipeline; you’ll see various screens, such as in the next figures.

And finally, you should see the completion screen.

Azure-Pipelines.yml File

Let’s pop back over to our GitHub repository and refresh – you should see the following.

You’ll see that the azure-pipelines.yml file has been added to our repo (this is important later).

I Thought We Wanted to Automate?

One of the benefits of a CI/CD pipeline is the automation opportunities it affords, so why did we manually execute the pipeline?

Great question!

We are asked to execute when we created the pipeline that is true, but we can also set up “triggers,” meaning we can configure the pipeline to execute when it receives a particular event.

In your Azure DevOps project, click “Pipelines” under the Pipelines section, then select the pipeline.

Then click “Edit” on the next screen (top right).

After doing that you should be returned to the azure-pipelines.yml file (we will return here to edit it later):

1. 1.

   Click the Ellipsis.

    
2. 2.

   Select Triggers.

    

Here, you can see the Continuous Integration (CI) settings for our pipeline.

You can see that the automation trigger is enabled by default (we have also configured this in the azure-pipeline.yml file), so now let’s trigger a build! But how do we do that?

Triggering a Build

Triggering a build starts with a git push origin master to GitHub, so really any code change (including something trivial like adding or editing a comment) will suffice. With that in mind, back in VS Code, open CommandsController class in the “main” CommandAPI project, and put a comment in our GetCommandItems method .

Everything should go as planned except when it comes to executing the final push command s .

What does this mean?

This pulls down the changes from the remote GitHub repository and merges them with our local one.

Indeed, if you look the VS Code file tree, you’ll see our azure-pipelines.yml file has appeared!

Now that we have synced our repositories, you can now attempt to push our combined local Git repo back up to GitHub (this includes the comment we inserted into our CommandsController class). Quickly jump over to Azure DevOps and click Pipelines ➤ Builds; you should see something like this.

A new build has been queued to start – this time triggered by a remote commit to GitHub!

Once it starts, all being well, this should succeed.

We are getting there, but there is still some work to do on our build pipeline before we move on to deploying – and that is ensuring that our unit tests are run – which currently they are not.

Revisit azure-pipelines.yml

Returning to our azure-pipelines.yml file in Azure DevOps (follow the steps earlier if you forgot how to get here), you should see the following.

This is of course the code we added before; you’ll notice it doesn’t perform any testing or packaging steps, yet.

Another VS Code Extension

As we are going to be doing a bit of editing of the azure-pipelines.yml file, there are two places you can do this:

1. 1.

   Directly in the browser (we’ve already done this)

    
2. 2.

   In VS Code

    

The advantage that editing in the browser had was that it gave you some Intellisense-like functionality where it suggested some code snippets, etc. However, Microsoft has now released a VS Code extension to provide similar functionality in VS Code, so we’re going to install and use that (it means we do all our coding in the one place).

In VS Code, click the Extensions button, and search for “Azure Pipelines”; you should see the following.

Install it, and then open azure-pipelines.yml file that we just pulled down from GitHub.

Running Unit Tests

Returning to the steps in our pipeline view, see Figure 12-37.

You’ll see the suggested sequencing is Build ➤ Test ➤ Release, so let’s add that task to our azure-pipelines.yml file now.

Move back to VS Code, open azure-pipelines.yml, and append the following Task after the build Task:

- task: DotNetCoreCLI@2

  displayName: 'dotnet test'

  inputs:

     command: test

     projects: '**/*Tests/*.csproj'

     testRunTitle: 'xUNit Test Run'

So, overall, the file should like this, again with our new task step highlighted.

The steps are quite self-explanatory, so save the file in VS Code, and perform the necessary Git command-line steps to commit your code and push to GitHub – this should trigger another build of our pipeline.

And this time the unit tests should execute too.

Click the dotnet test step as shown to drill down to see what’s going on; you should see something like the following.

Clicking the link highlighted in Figure 12-41 takes you to the test result dashboard.

Very nice! Indeed, this is the type of Information Radiator that you should make highly visible when working in a team environment, as it helps everyone understand the health of the build and, if necessary, take action to remediate any issues.

Breaking Our Unit Tests

Now just to labor the point of unit tests and CI/CD pipelines, let’s deliberately break one of our tests.

Back in VS Code and back in our CommandAPI.Tests project, open our CommandsController tests, and edit one of your tests, and change the expected return type; I’ve chosen the test here and swapped NotFoundResult with OKResult:

We’ll of course get a failing result.

Now under normal circumstances, having just caused our unit test suite to fail locally, you would not then commit the changes and push them to GitHub! However, that is exactly what we are going to do just to prove the point that the tests will fail in the Azure DevOps build pipeline too.

So, perform the three “Git” steps you should be familiar with now (ensure you do this at the solution level), and once you’ve pushed to GitHub, move back across to Azure DevOps, and observe what happens.

Then as expected, our test fails.

Again, you can drill down to see what caused the error, and if, for example, you were displaying test results on a large LCD screen, it would be immediately apparent that there is something wrong with the build pipeline and that remedial action needs to be taken. Looking at the individual steps, see Figure 12-47.

And then drilling further in to the dotnet test step and going to the test results dashboard (see Figure 12-48).

Testing – The Great Catch All?

Now, this shows us the power of unit testing in that it will cause the build pipeline to fail and buggy software won’t be released or even worse deployed to production! It also means we can take steps to remediate the failure.

So conversely, does this mean that if all tests pass, you won’t have failed code in production? No, it doesn’t for the simple reason that your tests are only as good as, well, your tests. The point that I’m making (maybe rather depressingly) is that even if all your tests pass, the confidence you have in your code will only be as good as your test coverage – ours is not bad at this stage though – so we can be quite confident in moving to the next step.

Before we do that though, revert the change we just made to ensure that all our unit tests are passing and that our pipeline returns to a green state.

Release/Packaging

Referring to our pipeline again, we’re now at the Release stage; this is where we need to package our build ready to be deployed.

So overall, your file should look like this, with the new code highlighted (again watch those spaces – the VS Code plugin we just installed should help you with this).

Save the file, and again: add, commit, and push your code. The pipeline should succeed, and if you drill into the successful build, you’ll see our two additional task steps.

Wrap It Up

We are now almost ready to deploy to Azure!