AZ-400: Microsoft DevOps Engineer Expert Certification Guide
Complete guide to the AZ-400 certification covering continuous integration, continuous delivery, Azure Pipelines, and DevOps best practices
AZ-400 - Microsoft DevOps Engineer Expert
- Design and implement processes and communications (10 - 15%)
- Design and implement a source control strategy (10 - 15%)
- Design and implement build and release pipelines (50 - 55%)
- Develop a security and compliance plan (10 - 15%)
- Implement an instrumentation strategy (5 - 10%)
Four pillars of continuous Integration
Version Control system > Package Management system > Continuous Integration system > Automated build process
| Continuous Integration | Continuous Delivery |
|---|---|
| Increase code coverage | Automatically deploy code to production |
| Build faster by splitting test and build runs | Ensure deployment targets have the latest code |
| Automatically ensure you dont ship broken code | Use tested code from the CI process |
| Run tests continually |
Key terms for Azure Pipelines
| Term | Description |
|---|---|
| Agent | An agent is installable software that runs a build deployment or deployment job. |
| Artifact | An Artifact is a collection of files or packages published by a build. |
| Build | A build represents the execution of a pipeline. |
| Continuous delivery | The process by which code is built, tested, and deployed to one or more test and production stages. |
| Continuous Integration | The practice used by development teams to simplify the testing and building of code. |
| Deployment target | A deployment target is a VM, Container, Web App, or any service used to host the developed application |
| Job | A build will contain one or more jobs. Most jobs run on an agent. |
| Pipeline | A pipeline defines the continuous integration and deployment process for your app. It is made of steps called tasks. |
| Release | When you use the visual designer, you can create a release or build pipeline. A release is a term used to describe one execution of a release pipeline. Its made up of deployments to multiple stages. |
| Stage | Stages are the primary divisions in a pipeline. |
| Task | Individual steps that make up a pipeline job |
GitHub Tags
Release Versions
Tag specific commits or releases as versions. Follow the semantic versioning notation, broadly accepted as de facto standard for labelling software releases. It is common to prefix your version names with the letter v (e.g. v1.0.0 or v2.3.4). If the tag isn't meant for production use, add a pre-release version after the version name (e.g. v0.2.0-alpha or v5.9-beta.3). This helps users and collaborators easily distinguish between stable releases and features that are still in the testing phase.
Feature releases
Tag commits or merges that introduce new features or significant changes to the codebase. Use descriptive tags like "feature/new-login-page" or "feature/payment-integration" to highlight specific feature releases. These tags provide a clear history of feature additions and help track the progress of individual features over time.
Bug Fixes
Tag commits or merges that address bug fixes or issues reported by users or collaborators. Use tags like bugfix/issue123" or "fix/critical-bug" to denote bug fix releases. Bug fix tags make it easy to identify commits that resolve specific issues and ensure that fixes are applied consistently across different versions of the project.
Maintenance releases
Tag commits or merges that involve maintenance tasks such as code refactoring, documentation updates, or dependency upgrades. Use tags like "maintenance/code-refactor" or "update/documentation" to mark maintenance releases. Maintenance release tags help track changes related to code maintenance and ensure that necessary updates are documented and applied correctly.