Sometimes starting from scratch is the best solution. A solution that often destroys what works but is not efficient. It is so inefficient that it cannot be scaled easily, it cannot be built further, it is often unreliable.
If you want to create a real CI/CD, such solutions require effort. An output that often just pays off. And now when there is a situation where most of the links are delivered by hand, the tests are run shortly before the product is delivered because: “no time”, releases are delivered late, the situation is quite critical.
Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way. - Jez Humble #CD #ContinuousDelivery— coffeina (@AndrzejDubaj) February 7, 2021
How to be sure that the product will be delivered to production, on time and without problems on the relapse day? A question that, on the one hand, builds curiosity, on the other, forces a smile on your face, and often even laughter. It doesn’t have to be this way, I assure you.
Back to the beginning when I started working on a certain project, the situation was bad. There was no such thing as deploy to production in every sprint, sprints did not last a week, two or three. There was indeed “some” test period in which the tests were performed, mainly manual ones. There was aloso some “release” periond which lasted as long as it took to prove everything to the production environment. You could dream about automation. Unfortunately, it was a sad picture, but true. A similar picture I have in several previous companies where I worked. However, everything can be straightened and improved;)
So sometimes the best solution is to burn everything down and build it up again.
This post is an introduction to a series of posts on CI/CD.