Les trois domaines que sont le développement, le contrôle qualité et la production se substituent donc l’un à l’autre au cours d’un processus unique et s’enchaînent sans cesse. Le produit traverse ainsi continuellement les différentes phases et est amélioré en permanence. Si le nombre de clients est important, ce processus nécessite une automatisation. C’est là qu’intervient la Continuous Delivery en automatisant l’intégralité du processus.
La Continuous Delivery permet de tester en temps réel toutes les modifications ou extensions du logiciel (c.-à-d. toute modification apportée au code source) pour recueillir un feed-back. Il est ainsi possible de détecter rapidement les effets indésirables afin d’intervenir à un stade encore relativement précoce. La Continuous Delivery se révèle notamment très utile en cas de bug pour déterminer avec plus de facilité quelle portion de code est à l’origine de l’erreur. Sans cette méthode, la recherche de problème est souvent très laborieuse.
Sur son parcours jusqu’au client, le logiciel passe donc par une étape intermédiaire que l’on appelle pipeline de Continuous Delivery, qui permet de réaliser des tests manuels ou automatisés. Chaque phase de test aboutit à une nouvelle version du logiciel (généralement nommée « version bêta » ou « Nightly Build », c’est-à-dire une version créée pendant la nuit). Cette nouvelle version est une nouvelle fois passée dans le pipeline. Ce n’est que lorsque le logiciel a réussi tous les tests et donné lieu à un feed-back satisfaisant qu’une version « stable » est créée et que le produit est officiellement publié (on appelle cette procédure, ainsi que l’application publiée à proprement parler, « mise à disposition »). La probabilité que le client reçoive un produit exempt d’erreur dans ce cas est nettement supérieure.