With the release process covered, John starts explaining to you how the service is deployed to production. It is very manual work: one member of the infrastructure team (IT) department copies the artifact to the server and executes a few commands to get it running.

John also takes the opportunity to add some stories of errors that they suffered in the past, like the time when, instead of deploying the latest version, the infrastructure operator mistakenly redeployed an old version. A bunch of old bugs reappeared and stayed in production until somebody found out what had happened.

While listening to those stories, you can't help but start thinking about what you have learned from previous projects and companies. You know that putting code into a production environment could be a very easy and straightforward task, a never-ending nightmare, or something in the middle. It depends on many factors and sometimes it is not up to us to change it. In some scenarios, deploying an application to production needs to be acknowledged by people who have the power to decide when and what is deployed. In others, there is strict regulation that turns what should be an easy procedure into a tedious and verbose task.

Furthermore, automating deployments is a way to reduce the risk factor that human interaction can add. Creating a repeatable process can be as easy as writing all the necessary steps in a script and scheduling its execution. It is well known that any single script can't replace a human completely, but, needless to say, the goal is not to replace humans with scripts. The main purpose of this is to provide a tool that can be executed autonomously and humans can supervise it, with manual intervention just in case it is necessary. For this, implementing continuous delivery is very suitable.

After John's brief but intense introduction, you feel that you are ready to start working on your own. You have many possible improvements in your head and you are definitely eager to implement them.