In my last post I described my view on Artifacts and Deployment Stages. Now it’s time to look at the Artifact flow.

Remember, an Artifact is unchangeable. Therefore it’s deployed only in one direction – strait forward – until any stage in the flow fails or it reaches the final destination.

Controlling the Flow

You control the flow – each stage – by these questions:

• When is a stage executed? … Trigger(s)
• Who allow the Artifact to enter the stage and what must be or informed? … Pre-Condition(s) and Gates
• Who say the stage is passed / what must be passed or informed? … Post-Condition(s) and Gates

Triggers

Stages in Azure DevOps Release Pipelines can be triggered by:

1. After an Artifact release
2. After other stage(s)
3. Manually

By using these automated triggers in the right way, you can organize the Artifact Flow:

Deployment in Stage “User Acceptance” is executed only after stage “Quality Assurance” succeeded.

Additional filters like “Artifact filters” helps to skip unwanted CI builds and avoid running the flow. Scheduling is useful to define a deployment window at least for production.

Approvals

Pre-, and Post-deployment approvals helps to control the Flow. It’s good to include the customer in this process. Who – e.g. the key users – must approve the correctness and allow a rollout of the Artifact into production?

Unstable Artifact(s) Flow

Artifact direct from Development – [dev] Branch – are mostly “unstable”. It’s useful to treat them separately in a own flow or CD pipeline.

Stage – Development / Test Automation

When an Artifact is generated by CI it will be deployed immediately in this stage(s). Consultants and developers can check the Artifact here. Test Automation is scheduled nightly. Approvals are not unnecessary.

Release Artifact(s) Flow

The used Artifact for this stage depends on your development process and your source code branching model. It’s the answer of the question(s): “What do you want to ship to your customer? What do you want to release?”

Stage – Quality Assurance

The “Release” Artifact can be scheduled – morning, lunch, … – for this stage to prevent unpredictable deployments and test results. Post approvals by consultants answer “passed” or “failed”.

Stage – User Acceptance Test

When “Quality Assurance” is passed the Artifact meets production data in a Sandbox or OnPrem Test System. Pre-approvals allow a manual release for this deployment into this stage and environment. Post-approvals by key users release the Artifact into the next stage or stop the flow – “passed” or “failed”.

Stage – Production

The “Release” reach this stage, when all previous stages are passed. The Artifact is tested, is approved, and is ready for deployment into customers production system. Pre-approval(s) allow the rollout and a scheduler define the deployment window.

What’s next

I’ll continue soon… With some insights into target environment(s) for the Release Artifact and publishing options from Azure DevOps.

I like to read your comments, suggestions, and be curious if you use another way to deploy your Artifacts.