Lecture 141: Introduction to CI/CD Processes

If you've ever worked on a dev team (or at least seen the memes about developers manually testing and deploying apps on a Friday night), you know how much of a headache building, testing, and deploying apps can be. That's where CI/CD comes in — like a superhero.

CI/CD stands for Continuous Integration (continuous integration) and Continuous Deployment/Delivery (continuous deployment/delivery). Yes, that's three words, and yes, it's two concepts — because Deployment and Delivery are sometimes distinguished and sometimes lumped together.

So, let's break them down separately:

Continuous Integration (CI):

Imagine your code is a giant puzzle you're assembling with your teammates. Every time someone adds their piece, the system checks that it fits with the rest and doesn't break what's already assembled. That's CI: the automatic build-and-test process after every change to the code. It helps catch bugs before they turn into a real headache.

Continuous Deployment/Delivery (CD):

• Continuous Deployment — this is when your code is automatically pushed to production servers after passing all tests. It's like "I did a git push, and five minutes later everything's live!".
• Continuous Delivery requires just one manual click from you to start the deployment process, while all tests and checks were already run automatically. It's useful when you want more control over releases.

Why CI/CD matters?

In short: CI/CD saves time, sanity, and money. But that's a bit abstract, so let's dive a bit deeper.

1. Automating boring tasks: you stop worrying about running tests manually and checking "does this even work?". The machine does it for you.
2. Finding bugs early: tests run after every code change. If someone "broke production", you catch it right away, not weeks later.
3. Faster time to market: you can deliver new features to users faster because build and test stages are sped up dramatically.
4. Fewer human errors: people forget. People get tired. People make dumb mistakes. Machines — not so much (well, almost not, if you set them up right).

Main stages of a CI/CD pipeline

Let's break down what a typical CI/CD pipeline consists of. It's like a chain of stations on an assembly line, each responsible for preparing your app.

1. Committing changes: developers make changes to the code and push them to the central repository (GitHub, GitLab, etc.).
2. Automatic build: at this stage your code is compiled, packaged into an artifact (for example, a JAR or WAR), and checked to see if it can even run.
3. Testing:
   • Unit tests: check small parts of the code.
   • Integration tests: check interaction between components.
   • End-to-End tests: check the whole app end-to-end.
4. Deployment to a test environment (staging): if tests pass, the app is deployed to a server for verification in conditions as close to production as possible.
5. Deployment to production: after testing on staging you can deploy the app to real users.

Examples: how it works in practice?

Imagine you're a developer. Here's how your day might look with CI/CD:

1. You made changes to the code and pushed them to GitLab.
2. GitLab CI kicks off an automated build of your app.
3. Unit tests check that the new code works correctly.
4. If tests pass, the app is deployed to a staging server, and you can verify everything works.
5. With a couple clicks (or automatically if Continuous Deployment is set up), the app goes to production.

Benefits of adopting CI/CD

Switching to CI/CD might seem hard and time-consuming at first, but here are the main reasons it's worth it:

1. Time savings: you no longer need to run tests manually, build the app, or upload files to the server yourself.
2. Improved product quality: with early bug detection and automated testing, your code becomes more reliable.
3. Faster releases: CI/CD lets companies ship updates more often and faster. As they say in the DevOps community, "deploy early, deploy often".
4. Stability and repeatability: the pipeline runs the same steps every time. No more "human factors".

Why is CI/CD considered an industry standard?

CI/CD didn't become standard just because it's trendy. This approach proved effective for companies of all sizes: from startups building their first product to giants like Google and Netflix.

Fun fact:

Netflix does thousands of deploys to production every day. That only became possible thanks to CI/CD and automation. Imagine if that was done manually — engineers would never sleep.

Tools we'll study

There are lots of tools to set up CI/CD. Here are a few popular ones we'll get familiar with:

• Jenkins: a very powerful and flexible tool for building pipelines. Although sometimes it feels like it deserves a medal "for the most outdated UI".
• GitLab CI: an integrated CI/CD tool for projects on GitLab. Convenient, minimalist, with a powerful YAML-based config.
• CircleCI: simple and popular, especially among Docker users. But it's not integrated with GitLab/GitHub, which can be a downside for some.

We'll start with Jenkins and GitLab CI — two tools commonly chosen for working with Spring Boot applications.

Discussion question: "Is CI/CD only for big companies?"

No way. Imagine you're building a small online store. Every time you add a new feature you need to check nothing broke. Setting up CI/CD frees up your time to work on features instead of manually testing the app.

Now that you've seen the theory, in the next lectures we'll move to practice: we'll create our Spring Boot application, set up a pipeline using Maven, and connect it to GitLab CI. Time to automate the boring stuff!