Creating and Using Release Candidate Packages

Let’s first look at the part of the process where release candidates fit. Figure 8-1 illustrates the sequence of events in our DevOps pipeline.

The release candidate packages are created by the CI build and are used by the deployment configuration. In Azure Pipelines, you will have a single continuous integration build for your application, regardless of the number of runtime components. For a single Git repository containing a Visual Studio solution, you will have one build. That build, upon success of all its steps, should package your application for deployment into a set of NuGet packages. We will cover how to determine the number of packages shortly.

Once the release candidate (the results of the build that is about to succeed) is packaged, the build configuration should push them into Azure Artifacts. Azure Artifacts provides a built-in NuGet feed for your team. Unless you have a specific reason to use something else, use this. Once the release candidate packages have been pushed, the CI build finishes and reports success. If the release candidate cannot be packaged or stored, then the build should fail.

While we have not yet covered release configurations or deployments (that will be covered in a later chapter), let’s cover the process that packages are used for. Each of the downstream environments (TDD, UAT, and Prod) will have a deployment process starting with the retrieval of the NuGet packages for the release candidate. This process will access the NuGet feed hosted in Azure Artifacts and retrieve the packages, extract them, and use the contents to deploy your application. The same packages making up a single release candidate should be used for deployment to every environment.

Defining the Bounds of a Package

Most applications have more than one runtime component. Therefore, there should be more than one NuGet package in the set of packages that make up a release candidate. Each part of your application that is deployed a specific way should be packaged separately, as shown in Figure 8-2. Let’s dig into how to determine the bounds of each package.

Let’s consider an application with three deployable components. The first part is a web application using ASP.NET. It is deployed to a web server or to Azure AppService. The second part is an off-line job. Perhaps a batch job or a handler service listening to a queue. These are very common, and they are deployed as Windows services or Azure Functions or WebJobs. The third is a SQL Server database. Whether on-premise or in Azure SQL, we must deploy schema and global data changes.

Each of these three components of the application run in their own memory space, in their own process, so they have differing deployment characteristics. The deployment destination is different. Because of these, each should be packaged in its own NuGet package. This allows each to be deployed to the appropriate destination while preserving flexibility. While you potentially could deploy all three components to a single server, you could also deploy each to completely different servers. In fact, you could deploy the web application ASP.NET UI to many servers in a web farm or to multiple Azure regions. The structure of your release candidate packages should map to the physical architecture of the running components of the application with a disregard to the topology of the server environment.

In addition to each application component, you will always have some additional assets that go along with the release candidate. These assets are not production code and only exist for validate of the release candidate. In Figure 8-2, you will see “Acceptance Tests.” In Visual Studio, this is manifested as a project, probably NUnit or another testing framework. If the application is a web application, the tests contained in the Visual Studio project likely use Selenium in order to test the fully deployed application. Because of the need for a fully deployed application, these tests are tied to the version of the application; therefore, they belong to a certain release candidate and need to be packaged and deployed along with the other components. In our process diagram earlier in the chapter, you saw that the TDD environment is the first environment for deployments. After the application is fully deployed, the acceptance test package will be retrieved and installed on a deployment server. Then, the tests are run against the deployed release candidate running from the TDD environment. In this way, we can package additional assets for the purpose of making our DevOps pipeline more robust so that it can detect a higher percentage of defects before promoting the release candidate to the next downstream environment.

Specifying How Packages are Created

To close the loop on how packages are made, refer back to our build script, which you will want to keep at the top level of your Git repository. Refer to Figure 8-4.

Since we have four components that must be deployed, we have four NuGet packages. Notice that I am using the Octo.exe tool.⁶ OctoPack is the full name and is an open source wrapper for NuGet, and you can find the source on GitHub. NuGet was originally designed as a package format for library dependencies before it was adapted for application packaging. You can certainly use NuPack directly, but OctoPack wraps NuPack and overcomes some of the default conventions and assumptions that don’t quite fit naturally when packaging an application component for deployment.

With the preceding PowerShell in our build script, we can configure Azure Pipelines as shown in Figure 8-5.

The Pack function is the last to be called. Then, with the NuGet packages properly created, our “NuGet push” build step places them in the Azure Artifacts services, which makes them available to any other process that accesses the NuGet feed. Refer to Figure 8-6.

Because we have the database migration tool and the full body of scripts, we are able to run the database migration process from any server we choose. And including helper ∗.ps1 files in our packages will limit the steps that must be explicitly configured in Azure Pipelines.

While YAML will become the format for all builds and releases, the tooling for that capability is not ready yet. Expect to move to YAML-based configurations at the right time. YAML will enable you to store your entire pipeline configuration in your Git repository.

Use Release Candidate Packages in Deployment Configurations

While we will go in depth on deploying in the next chapter, it is useful to know how a build or release configuration can retrieve a NuGet package from Azure Artifacts on demand, as shown in Figure 8-7.

Remember the order of our environments. In the case of the TDD environment, you will need to deploy the full application and then pull and install the AcceptanceTests package so that those tests can be run. The AcceptanceTests package lives no further than the TDD environment. If you create other types of test suites that must be run on a fully deployed environment, you would use the same pattern of packaging them as a package, storing them in Azure Artifacts, and retrieving them during deploy.

The “Download Package” step allows for easy retrieval of our set of NuGet packages for any release candidate, as shown in Figure 8-8. Because a NuGet package is essentially a ∗.zip file with a manifest, this step retrieves and extracts the NuGet package on the destination directory of the server that is used as the agent, whether it is a hosted agent or your own private agent. You can see how important the build number is to the pipeline. Everything ties back to the build number.