Microsoft Certified: DevOps Engineer ExpertDesign and implement pipelinesMedium
A company is migrating its monolithic application to a microservices architecture. Each microservice will have its own independent CI/CD pipeline. The company wants to implement a strategy where the deployment of a specific microservice to the production environment is automatically triggered only after a successful deployment of a critical dependency microservice to the same environment. This dependency must be managed within Azure DevOps release pipelines. How should this inter-pipeline dependency be configured?
- AImplement a custom script in the dependent microservice's pipeline to poll the status of the critical dependency.
- BConfigure a scheduled trigger for the dependent microservice's pipeline.
- CAdd a 'Release' trigger to the dependent microservice's pipeline, specifying the critical dependency pipeline.
- DUse an artifact filter on the dependent microservice's pipeline.
Show answer & explanationAnswer & explanation
Correct answer: C. Add a 'Release' trigger to the dependent microservice's pipeline, specifying the critical dependency pipeline.
Azure DevOps release pipelines support 'Release' triggers, which allow one release pipeline to be automatically triggered upon the successful completion of another release pipeline. This directly addresses the requirement for sequential deployment based on a critical dependency.
Why the other options are wrong
- A. Implementing a custom script for polling is an inefficient and complex workaround when a native feature ('Release' trigger) exists for this exact scenario.
- B. A scheduled trigger initiates releases at specific times, not based on the successful deployment of another microservice.
- D. Artifact filters control which artifact versions trigger a release, not the completion of another release pipeline.
Release Trigger (Azure DevOps)
A Release Trigger in Azure DevOps allows you to automatically initiate a release pipeline based on various events, including the successful completion of another build pipeline, a scheduled time, or the successful completion of another *release* pipeline.
- Supports chaining release pipelines for complex deployments.
- Ensures dependent services are deployed in a specific order.
- Can be configured to trigger on successful deployment to specific stages.
Memory trick: One release's success triggers the next's start.