There is a lot of detail in the following overview diagram of the CD pipeline, and you most likely won't be able to read all the text. Don't worry about this at the moment; we are going to delve deeper into the details as we go along.

For the time being, it is enough to understand that when we work with DevOps, we work with large and complex processes in a large and complex context.

An example of a CD pipeline in a large organization is introduced in the following diagram:

While the basic outline of this diagram holds true surprisingly often, regardless of the organization, there are, of course, differences, depending on the size of the organization and the complexity of the products that are being developed.

The early parts of the chain, that is, the developer environments and the CI environment, are normally very similar...

So far, we have assumed that the release process is mostly automatic. This is the dream scenario for people working with DevOps.

This dream scenario is a challenge to achieve in the real world. One reason for this is that it is usually hard to reach the level of test automation needed in order to have complete confidence in automated deploys. Another reason is simply that the cadence of business development doesn't always match the cadence of technical development. Therefore, it is necessary to enable human intervention in the release process.

A faucet is used in the following diagram to symbolize human interaction—in this case, by a dedicated release manager:

How this is done in practice varies, but deployment systems usually have a way to support how to describe which software versions to use in different environments.

The integration test environments...

How does the CD pipeline that we described in this chapter support Agile processes such as Scrum and Kanban?

Scrum focuses on Sprint cycles, which can occur biweekly or monthly. Kanban can be said to focus more on shorter cycles, which can occur daily.

The philosophical differences between Scrum and Kanban are a bit deeper, although not mutually exclusive. Many organizations use both Kanban and Scrum together.

From a software-deployment viewpoint, both Scrum and Kanban are similar. Both require frequent, hassle-free deployments. From a DevOps perspective, a change starts propagating through the CD pipeline towards test systems and beyond when they are deemed ready enough to start that journey. This may be judged on subjective measurements or objective ones, such as all unit tests are green.

Our pipeline can manage the following types of...

So far, we have covered a lot of information at a cursory level.

To make it clearer, let's have a look at what happens to a concrete change as it propagates through the systems, using an example:

• The development team has been given the responsibility of developing a change to the organization's system. The change revolves around adding new roles to the authentication system. This seemingly simple task is hard in reality because many different systems will be affected by the change.
• To make life easier, it is decided that the change will be broken down into several smaller changes, which will be tested independently and mostly automatically by automated regression tests.
• The first change, the addition of a new role to the authentication system, is developed locally on developer machines and given best-effort local testing. To really...

As is apparent from the previous example, there is a lot going on for any change that propagates through the pipeline from development to production. It is important for this process to be efficient.

As with all Agile work, keep track of what you are doing, and try to identify problem areas. It is important to continuously improve your processes, which is often referred to as Kaizen, which is a Japanese term. You may discover new technical improvements as times goes on, or simplifications of your processes—"Everything should be made as simple as possible, but no simpler," a saying which is often attributed to Albert Einstein.

When everything is working as it should, a commit to the code repository should result in the change being deployed to integration test servers within a 15-minute time span.

When things are not working well, a deploy...

In this chapter, we delved further into the different types of systems and processes you normally work with when doing DevOps work. We gained a deeper, detailed understanding of the CD process, which is at the core of DevOps.

In the next chapter, Chapter 3, How DevOps Affects Architecture, we will look into how the DevOps mindset affects software architecture to help us achieve faster and more precise deliveries.