loading...
Cover image for ๐ŸŽฏ What is Continuous Delivery and why should you start using it right now?

๐ŸŽฏ What is Continuous Delivery and why should you start using it right now?

koddr profile image Vic Shรณstak ใƒป3 min read

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.

โ†‘ Table of contents

Why should I start using it?

With Continuous Delivery, it's easier to know all problems before its happen:

  1. You write the code.
  2. 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.

โ†‘ Table of contents

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.

โ†‘ Table of contents

Books

โ†‘ Table of contents

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! ๐Ÿ˜‰

โ†‘ Table of contents

P.S.

If you want more โ†’ write a comment below & follow me. Thanks! ๐Ÿ˜˜

Posted on by:

koddr profile

Vic Shรณstak

@koddr

Hey! ๐Ÿ‘‹ I'm founder and full stack web developer (Go, JavaScript, Docker & automation) at True web artisans. Golang lover, UX evangelist, DX philosopher & UI Dreamer with over 12+ years of experience.

Discussion

markdown guide