In the day-to-day life of a team that develops software, new features are added to the current system, or existing ones are improved. So, delivering a new version is basically improving the system.
Who usually delivers the system (and ideally) is the developer group. And often the delivery process is dominated by the development team. Let’s cite an example:
“Deployment is manual and risky, so only a certain group of more experienced people are responsible for putting the new version into the air.”
In that case, even if the company’s Business team decides a date to deliver the new version, it would not be a decision of it, but the development team, if they could carry out the deployment.
If deliveries are not very frequent, or have no frequency at all, it is even harder to decide when to deploy.
It’s quite common to freeze the current version in times of risk – during a big sales promotion. There is no predictability and confidence in what will happen when a new version is delivered.
Making frequent deliveries is even more crucial for startups, as new ideas need to be tested and evaluated quickly.
Okay, so we need to improve the delivery process so that the business team makes the decisions without relying on the development team. How do we do it?
Going back in time
A few years ago we started to adopt automated tests, letting the machine do what it is good, repetition, and letting humans do what they are good to exploit.
Automating the manual testing process was such a good thing that it even evolved into TDD, a technique where automated testing is done before code implementation.
And do not stop there. After automating the tests, we also decided to automate the execution of them. So every possible change of system goes through the entire suite of tests and the team receives feedback much faster.
Following this line of reasoning, automation emerges as an answer to this problem. Automating the way the software is delivered gives greater predictability and confidence to the process, making the development team no longer a dependency.
Back to the future
To develop a robust Continuous Delivery Process we must ensure that what is delivered will be of quality.
The Continuous Integration server runs only the local tests, but how do I know if the external services (software / hardware) are working? How to know if this code will work as expected outside of the development environment?
Extrapolating the idea of Continuous Integration, we can think of a Pipeline of Implementation (Build Pipeline).
The idea is that each piece of code, in addition to being tested by automated testing, is also implemented on an approval server. This way, not only the code is tested, but also the infrastructure and the database.
Tools that control and version the configuration of the machines and the database are very important at this point, because they make it easier to go back and check where the problems are.
In short, each generated commit will go through the entire test suite, then it will be deployed in an approval environment and integration testing will be done there, ensuring that everything runs smoothly.
Want to put the newest version of the system in the production today? Just use the last commit that went through Pipeline!
In the same way it is easy to get back the version in case of serious problems in production. Just use the last functional commit and perform a new deployment.