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.
- Maximize automation strategy with build triggers
- Understand hybrid build concepts
- Speed up pipelines with parallel builds
- Learn about build tools and Azure integration
- Anyone wanting to learn the continuous integration material for Microsoft's AZ-400 exam
- 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
The GitHub repository for this course is at https://github.com/cloudacademy/azure-continuous-integration-build.
Proper utilization of multi-agent or parallel builds is one of the most effective optimizations that can be performed. With careful strategy, significant time can be saved. However, as often the case, such efficiency comes at the cost of greater complexity and more stringent requirements. In this section, we will cover the criteria that needs to be met to enable parallel builds and the application of parallelism in Azure DevOps pipelines.
Azure Pipelines wants to run builds in parallel and will do so unless the conditions are not agreeable.
Let's look at what criteria must be met to allow parallelism.
Since build agents do the heavy lifting, more than one build agent is required if parallelism is desired. In fact, not only can't a build be optimized to run in parallel, only one build or deployment can be run at one time with a single agent.
In relation to having more than one agent for an account, more than one agent must be available for the build to run in parallel. For example, an account could have five agents, but if four are busy running other builds or deployments, then only one is available for the build.
Also, the Azure Pipelines YAML file must be structured to run in parallel. This means that the build steps must be able to be broken into distinct jobs.
Furthermore, the number of jobs that can be run in parallel are limited by the availability of agents to run those jobs. For instance, if a build has four jobs that can be run concurrently, but only three agents are available, then only three jobs will be run in parallel at one given time unless another agent becomes free.
Given that jobs run in parallel when the agent availability criteria is met, breaking the pipeline down into multiple jobs is the only direct correlation between the Azure Pipelines' YAML and parallelism.
Simply adding more jobs, each with at least one step, is enough to support multi-agent builds for a pipeline.
Adding more than one stage will also accomplish parallelism since, inherently, a stage has at least one job.
Stages and jobs can be added to further optimize the pipeline where it makes sense to do so.
There are often times when parallelism isn't desired. This could be due to a dependency or the overhead of running a job in parallel.
Simply adding the dependsOn syntax under the job will prevent the job from running before the dependency. For example, adding dependsOn under the test job and specifying the validate job will ensure that the validate job is completed prior to running the test job.
The same can be accomplished when using stages. Just make sure the syntax is at the proper level.
Typically, the dependsOn syntax is placed close to the top of the job or stage to make the code logic more clear.
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.