Controlling the Artifact Flow – CI / CD Part 2

Controlling the Artifact Flow – CI / CD Part 2

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

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


Stage 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.

Release Flow

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.


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.

Unstable Artifact Flow

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?”

Release Artifact Flow

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.


3 thoughts on “Controlling the Artifact Flow – CI / CD Part 2

  1. A powerful share, I simply given this onto a colleague who was doing a bit of analysis on this. And he actually bought me breakfast because I found it for him.. smile. So let me reword that: Thnx for the treat! But yeah Thnkx for spending the time to discuss this, I feel strongly about it and love reading extra on this topic. If possible, as you become expertise, would you thoughts updating your blog with extra details? It’s highly useful for me. Big thumb up for this blog post!

  2. Sorry for the format issue – did you tried an actual version or another browser?

Comments are closed.

Comments are closed.