Gitlab 1-6 Adoption of the ci cd culture method

In this lesson we adopt the CI/CD work culture. Now that we have seen the issues of the older workflow, we can examine how CI/CD removes those issues and lets us ship faster and with fewer mistakes.

What changes for developers

Because CI/CD is not a tool, a technology or a programming language but a methodology, developers do not have to learn anything radically new or acquire new technical skills. They mostly have to change their way of working and adopt a small set of principles that enable frequent code delivery. In the conventional approach we saw earlier, code travelled across many teams and the final version only arrived after several weeks. Each team had its own piece of code to work on, and everything was merged at the end.

The CI/CD method changes that picture. There is now a single shared repository, and every team works on it. Every change or modification must be pushed back to the repository almost instantly — developers do not hide changes for days. They can still keep a feature branch on the side, but it has to be pushed regularly to avoid confusion. Code delivery happens often: several times per day at the start, and at minimum at the end of each day. Each change is notified into the repository.

A build server automates the heavy lifting

When developers integrate code regularly, the verification time per integration drops to almost zero. To make that happen, a build server is deployed: it automatically integrates the code that has just been pushed and can also run the test suite. With this server in place, no human is needed to build the code or chain the manual steps — everything is automated.

That is the heart of Continuous Integration: whenever a developer pushes code, it is automatically launched on the build server, built and turned into a package. If there is an error in the code, you know within minutes rather than weeks. For example: I push a faulty commit, three minutes later the build server tells me it broke, I fix it on the spot. Defects that used to take weeks to surface now come back in minutes.

On the operations side, the same logic applies. Many of the instructions handed off to ops were simple enough to be replaced by scripts. We can ask developers to script their deployment steps, or even let a different team write those scripts. We do not assume someone building a mobile app must necessarily be the one writing the deployment scripts — but with CI/CD they can take on that role. Replacing manual effort with scripts removes a huge amount of repetitive human work and improves overall quality. The CI/CD steps end up easy, fast, and dramatically faster than the old way. Thanks for watching.