Introduction
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.
📝 Table of contents
What is Continuous Delivery?
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.
Why should I start using it?
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.
Okay, I got it! What's next?
I offer you a list of books and services to help you explore and start using Continuous Delivery and Integration.
Books
- Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and David Farley
- Software Delivery Guide by Martin Fowler
Services
Personally, I use GitHub Actions, because all of my projects holds on GitHub. But you can find many more such services (paid or free), for example:
I recommend to try each of them to understand exactly what will be convenient for you! 😉
P.S.
If you want more articles (like this) on this blog, then post a comment below and subscribe to me. Thanks! 😻
❗️ You can support me on Boosty, both on a permanent and on a one-time basis. All proceeds from this way will go to support my OSS projects and will energize me to create new products and articles for the community.
And of course, you can help me make developers' lives even better! Just connect to one of my projects as a contributor. It's easy!
My main projects that need your help (and stars) 👇
- 🔥 gowebly: A next-generation CLI tool that makes it easy to create amazing web applications with Go on the backend, using htmx, hyperscript or Alpine.js and the most popular CSS frameworks on the frontend.
- ✨ create-go-app: Create a new production-ready project with Go backend, frontend and deploy automation by running one CLI command.
Top comments (0)