Build and Testing

Introduction

The word “fast” is defined as “moving or capable of moving at a high speed.” High speed is the key takeaway from a Continuous Integration and Continuous Delivery (CICD) pipeline, but going fast isn’t everything. In CI/CD, you must also be efficient. You must work in a way that doesn’t break the environment, the code, or the application that’s being deployed.

Efficiency, or a way to achieve maximum productivity combined with moving quickly or fast, is what makes a CI/CD pipeline like Azure Pipelines so efficient.

Azure Pipelines are a way to automatically build, test, and deploy code in any environment, including on-prem and cloud. The premise behind Azure Pipeline is three-fold:

• Build: Packaging code in a central location. A build can either deploy the code from the source (like GitHub or Azure Repos) or turn it into an artifact. Artifacts are a packaged version of the code. To get the code packaged, various actions take place to ensure it’s in a deployable state like a test.

• Test: Tests ensure code is ready to be deployed with all of its dependencies and as few bugs as possible.

• Deploy: Deployments send the code to its destination. Deployments actually apply the code to the environment and make it available for use.

Stay tuned as we break down each important facet of CI/CD and Azure Pipelines in this chapter.

Builds

The build process in a CI/CD pipeline is whatever actions you need to take to package up a collection of files in source control into a deployable state. Those actions can be many different things. But, in the end, the build is a set of actions to prepare the code for deployment.

Code stored in source control is consumed by the build process. The build process then gets the code ready to be in an executable state. Once the code is in an executable state, it can be run on a computer or by a specific build tool.

When a build runs, it can return various states from failed, succeeded, and other states in between.

A publisher is a component of the build process in Azure DevOps. A publisher reports which components ran successfully and which did not. For example, if a Pester test fails, then the Pester publisher report may be entirely unstable. Essentially, a publisher is a person or company that creates a task that you may or may not be using. All extensions/tasks, even ones created by Microsoft, are identified as a Publisher.

For example, perhaps you’re running a build from a PowerShell module you’ve developed and the build step has a Pester test inside of it. You’ll sometimes see smaller tests inside of the build phase rather than the “official” testing phase like this. If the build completes successfully, but the publisher, Pester in this case, doesn’t pass the test, the build will be deemed unstable.

A successful build is a build that has passed all of the tests, has any dependencies or requirements it needs, and is ready to be used.