The course is part of these learning paths
Azure DevOps is a tool for planning, auditing, code versioning, code integrating, testing, artifact storing, and deploying. It is the primary tool for continuous integration and deployment. This course will focus on the most important parts of Azure Pipelines in implementing an end-to-end continuous integration strategy.
Build triggers are essential for automated code processing and will reduce the workload of any team governing the process. You will learn which build triggers exist, why you may want to use them, and a strategy for implementing them.
Hybrid builds allow for flexibility in workflow, security, and processes by integrating builds from more than one pipeline or tool.
Parallel builds will speed up processing of the workflow where it makes sense to do so. You will learn how to use parallel or multi-agent builds, when to use them, and what their benefits are.
Azure DevOps is but one tool in the CI ecosystem. This course will also touch upon other build tools as well as recommendations for their use and integration into your workflow.
To round out the course, we will set up a completely automated continuous integration (CI) workflow that will provide a foundation for a secure, repeatable, auditable, and complete CI solution for your projects.
Learning Objectives
- Maximize automation strategy with build triggers
- Understand hybrid build concepts
- Speed up pipelines with parallel builds
- Learn about build tools and Azure integration
Intended Audience
- Anyone wanting to learn the continuous integration material for Microsoft's AZ-400 exam
Prerequisites
- A basic understanding of workflow and the CI build pipeline process
- A good understanding of the development lifecycle
- It would be advantageous to have a basic understanding of YAML, although it's not required
Resources
The GitHub repository for this course is at https://github.com/cloudacademy/azure-continuous-integration-build.
Hybrid builds make it possible to perform parts of a build on one or more platforms. This may be due to security requirements, proprietary software, resource allocation, tooling availability, compliance requirements, optimization strategy, or any multitude of other reasons.
For example, security concerns may prevent building sensitive code outside of private infrastructure. However, the cloud would be beneficial for platform testing. With hybrid builds, application code can be built on-premise and the artifact pushed to storage. From there, public infrastructure can be utilized for further testing and deployment.
Having a good design is paramount with any build, but hybrid builds require more planning due to the complexity of using more than one platform.
Isolating what parts of the build should be done on which platform is a good first step. The primary consideration for segregation is the level of interdependence. Each build will need to achieve a finish state that results in some complete action or artifact.
For example, a scenario where an application pipeline needs to start on-premises for security reasons but for optimization, the build process utilizes the public cloud to perform testing and deployment is a good use case. The build process starts the application build on-premises and produces an artifact as a docker image. The image is pushed into a private docker registry. From there, the public cloud is engaged to do integration, stress, and platform testing. If successful, the docker image is promoted for deployment.
Breaking down this process and identifying definite stages of transition is a good start. The other consideration is the trigger to start the testing process. For this example, there are multiple options for triggering the testing phase. The docker registry could be set to initiate upon a new push; a specific branch, tag, or comment could be used in conjunction with a Git repository; or triggering the pipeline directly using an API call at the end of the build phase.
There are many ways to accomplish hybrid builds. One such way is to use a pipeline tool, like Jenkins, on-premise. The tool can be configured to trigger on a push to a specific branch or branches. The result from that build could then further be processed in Azure DevOps.
Let's look at how this may be implemented. I've created a Jenkins file with some mock stages and steps to illustrate how a build might be configured. The Jenkins file will test the code, build the artifact, and then store the artifact. The last stage is to kick off any downstream automation.
In this case, an Azure pipeline's kickoff is being locked. Typically, any failure at any point would result in a terminated failed build. This pipeline is counting on that behavior. The downstream automation should never occur if an error exists prior to this stage. The trigger for the succeeding build is usually the most technical part of a hybrid build. Careful consideration must be given in order to execute the handoff properly. Here, the Azure DevOps API or the Azure CLI could be used to kick off the Azure pipeline's build.
Let's look at the Azure Pipelines file to round out this hybrid design. The Azure Pipelines file contains the trigger specification, the pool, and the testing stage with parallel capable jobs for integration and stress testing. Of course, this is only an example. Much more can be done here.
Lectures
Cory W. Cordell is an accomplished DevOps Architect, Software Engineer, and author. He started his DevOps career as a DevOps Engineer for a large bank where he helped implement DevOps practices and tooling and establish a DevOps culture.
Cory then accepted a position with a global firm to build a DevOps department. He led a team of DevOps Engineers to establish best practices and train development teams on tooling and those practices. He worked to help development teams migrate their applications to Azure Kubernetes Service and establish pipelines to build, test, and deploy code. Realizing that a substantial gap existed in the toolchain, he developed an application to aid in infrastructure tracking and to provide UI abilities for teams to view application status for their software.
Cory is now enjoying working as a contractor and author.