Continuous delivery

A continuous delivery pipeline could have a manual gate right before production. A manual gate requires human intervention, and there could be scenarios in your organization that require manual gates in pipelines. Some manual gates might be questionable, whereas some could be legitimate. One legitimate scenario allows the business team to make a last-minute release decision. The engineering team keeps a shippable version of the product ready after every sprint, and the business team makes the final call to release the product to all customers, or a cross-section of the population, or perhaps to people who live in a certain geographical location.

The architecture of the product that flows through the pipeline is a key factor that determines the anatomy of the continuous delivery pipeline. A highly coupled product architecture generates a complicated graphical pipeline pattern where various pipelines could get entangled before eventually making it to production.

The product architecture also influences the different phases of the pipeline and what artifacts are produced in each phase. The pipeline first builds components - the smallest distributable and testable units of the product. For example, a library built by the pipeline can be termed a component. This is the component phase.

Loosely coupled components make up subsystems - the smallest deployable and runnable units. For example, a server is a subsystem. A microservice running in a container is also an example of a subsystem. This is the subsystem phase. As opposed to components, subsystems can be stood up and tested.

Therefore, the pipeline can be taught to assemble a system from loosely coupled subsystems in instances where the entire system should be released as a whole. This is the system phase.

This all-or-none approach causes the fastest subsystem to go at the speed of the slowest one. “The chain is only as strong as its weakest link” is a cliche we use to warn teams who fall prey to this architectural pattern.

Once validated, the assembled system is then promoted to production without any further modification, in the final phase, called the production phase.

Note that these phases are more logical than physical, and created only to break down a large problem into multiple smaller sub-problems. You may have less phases or more, depending on your architecture and requirements.

Speed without quality is useless to our customers. Continuous testing is a technique where automated tests are integrated with the software delivery pipeline, and validate every change that flows through it. Tests execute in each phase of the pipeline to validate artifacts produced in that phase. Unit tests and static code analysis validate components in the component phase of the pipeline. Functional, performance, and security tests validate subsystems in the subsystem phase. Integration, performance, and security tests validate systems in the system phase. Finally, smoke tests validate the product in the production phase.