As you move toward continuous delivery, you will incrementally improve each of these foundation capabilities:
Developer responsibility: Developers will approve releases. It is the responsibility of the developers to make sure that their code doesn't break anything. Their code should be releasable. They can't just throw it over to QA and wait for bug reports. They will be motivated to write automated tests. Developers will make decisions about what to release. QA professionals should serve in a consulting role to help developers as needed.
Feature switches: Developers can release code for new features continuously by hiding features that aren't ready. When you are adding significant new features or making architecture changes, you will in most cases be running both old and new versions of your software at the same time. In following chapters we will cover the hiding and "unveil" tactics that make it possible to smoothly sneak big changes into a continuously released system.
Code contribution: You will want to use one of the continuous delivery code contribution patterns described here - centralized, distributed, or hybrid.
Test Layering: You will learn how to add layers of tests so that you can be confident that every change will work well on release. You will want enough automated tests to tell you immediately if something is broken. You run them frequently. You log and monitor your running software to see errors and understand usage. You will add tests and test layers when you need to increase quality, or you will remove tests and test layers to increase speed.
Automated builds: Manually building and distributing software takes too much time and results in too many errors. You will need scripts to build and deploy your software. And, if you want to release more frequently, you need someone to release to.
Continuous Improvement: You do not need all of these things to release more frequently. You can move to continuous delivery incrementally, in two simple steps.