Modern Pipeline

Many teams struggle with slow delivery. Release cycles are getting longer and longer. Teams are stuck with Manual QA. We lose customers because our software is buggy. How to solve this problem?

🚀 Are you frustrated by long Manual QA cycles? Do you want stop Regression Bugs escaping to production? Join me at my next FREE live event: “Stop Breaking Production: ATDD in Legacy Code” (Sep 17 at 5:00 PM CET).

---

The only way to be able to deliver safely and quickly into production is through Continuous Delivery (Jez Humble):

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

Our goal is to make deployments—whether of a large-scale distributed system, a complex production environment, an embedded system, or an app—predictable, routine affairs that can be performed on demand.

We achieve all this by ensuring our code is always in a deployable state, even in the face of teams of thousands of developers making changes on a daily basis. We thus completely eliminate the integration, testing and hardening phases that traditionally followed “dev complete”, as well as code freezes.

The foundation of Continuous Delivery is the Pipeline.

Pipeline

The Pipeline is composed of at least 3 stages:

1. Commit Stage - automatic verification whether Components work (in isolation)

2. Acceptance Stage - automatic verification whether the System works (as a whole)

3. Release Stages:

   1. QA Stage - QA verification whether the System works

   2. UAT Stage - business validation whether System meets business needs

   3. Staging Stage - final validation in a production-like environment

   4. Production Stage - releasing to the End User

It should be noted that the Acceptance Stage is responsible for the automated verification of functional requirements only. To verify non-functional requirements, we need additional stages, e.g.:

• Performance Stage - verify whether the System meets performance requirements

• Security Stage - verify whether the System meets security requirements

Note: There are no limitations regarding this list of Stages. Please structure it based on non-functional requirements.

Commit Stage

The goal of the Commit Stage is to verify that Components work in isolation & publish their Artifacts.

The Commit Stage is triggered when developers push changes to the Version Control System.

For each Component, the following are the key steps in the Commit Stage:

1. Checkout the Component code

2. Compile the Component code

3. Verify that the Component works correctly (in isolation)

   1. Run Unit Tests

   2. Run Narrow Integration Tests

   3. Run Component Tests

   4. Run Contract Provider Verification Tests

4. Verify that the Component’s code is maintainable, secure, etc.

   1. Run Linter

   2. Run Static Code Analysis

5. Publish Component’s Artifact to the Artifact Repository

   1. Build Artifact

   2. Publish Artifact