Hello, DEV people! 👋 Currently, there are many tools that help programmers (and not only) to do their job as comfortable and high-quality as possible.
I got an article, that explains "what is continuous delivery?" in a very accessible language, which I'm in a hurry to share with you!
☝️ Please note: this is a translation (with some corrections) of original article was written by Fedor Borshchev.
- What is Continuous Delivery?
- Why should I start using it?
- Okay, I got it! What's next?
Continuous Delivery (or CD) is a practice where the content of the master branch of the repository is always in production: made a commit and the server automatically updated, and so several times a day.
Usually, delivery is the final part of the Continuous Integration (or CI) process.
In a classic release cycle, it's common to save changes to large packs and put them all together. Say, if you made two features in one day, one of which changes the data structure and the other adds useful functionality for users, they will go together in the production.
If migration from the first feature does not work (for some reason), the second feature with useful functionality will most likely not work either.
Or you have been making a big feature for a week, which requires updating the framework version, making five different migrations and running 2000 lines of code.
In a classic release cycle, you will most likely run it at once, and if anything goes wrong in any of these parts, you will know at the very last moment, close to the deadline.
With Continuous Delivery, it's easier to know all problems before its happen:
- You write the code.
- Then, you put it on production.
You can even delivery in parts, our giant 2000 lines feature can be delivered in four small pieces. It turns out that by the time of launch, most of your code will be in production.
Which means, that all the things that could have been shot at the time of publication, such as ongoing migrations, are likely to be shot in advance.
Running continuous delivery is a sign of a high engineering culture. For example, in the classical approach, every release is a big job for the tester: you have to check with your hands, that nothing has broken.
If you deliver code several times a day, you will either have to hire an unreasonable number of testers or you will still have to automate testing.
You will also have to automate code delivery. If you're used to manually move files and start compiling assets, you will not get any Continuous Delivery.
I offer you a list of books and services to help you explore and start using Continuous Delivery and Integration.
- Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and David Farley
- Software Delivery Guide by Martin Fowler
I recommend to try each of them to understand exactly what will be convenient for you! 😉
If you want more → write a comment below & follow me. Thanks! 😘