CodeGym /Courses /Module 5. Spring /Lecture 146: Practice: setting up a CI/CD pipeline in Git...

Lecture 146: Practice: setting up a CI/CD pipeline in GitLab

Module 5. Spring
Level 22 , Lesson 5
Available

In this lecture you'll learn how to:

  1. Create and configure a pipeline in GitLab CI for a Spring Boot application.
  2. Implement build, test, and deploy stages.
  3. Understand how to monitor pipeline runs and troubleshoot failures.

So get ready! Setting up a CI/CD pipeline is like reinstalling an OS: you don't wanna do it, but afterwards everything works (well, at least it should).


Why we need a CI/CD pipeline

Every time developers add new code, our build, test, and deployment process should run automatically. This speeds up development a lot and reduces human error (so, fewer "oops" bugs).

Real-world scenario

Imagine your team is building a Spring Boot application. Every commit to the repo triggers a pipeline that:

  • Checks that the project compiles.
  • Runs all automated tests.
  • Deploys the app to a test and/or staging environment.
  • Eventually, rolls the verified app out to production.

If the pipeline fails, GitLab will show you exactly where it broke. That's what we'll set up.


Building the pipeline: main stages

Let's start by creating a .gitlab-ci.yml file at the root of our project. This is the "heart" of the GitLab CI pipeline, where we describe all the stages.


stages: # Define the stages of our pipeline
  - build
  - test
  - deploy

Here we list the main stages:

  1. build: building the project.
  2. test: testing (unit and/or integration tests).
  3. deploy: deploying to a staging or production environment.

The "build" stage is responsible for building our app. For Spring Boot we'll use Maven.


build:
  stage: build
  image: maven:3.8.5-openjdk-17 # Docker image with Maven and Java 17
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar # Save built JAR artifact
  only:
    - main # Run this stage only on the main branch

Let's go over the key points:

  • image: the Docker image where this stage runs (here: Maven + JDK 17).
  • script: commands to run. We're using mvn clean package to build the project.
  • artifacts: store the final artifacts (in this case, JAR files).
  • only: run this stage only for the "main" branch so we don't build every feature branch.

Now let's add testing. This stage is important to make sure new code doesn't break existing functionality.


test:
  stage: test
  image: maven:3.8.5-openjdk-17
  script:
    - mvn test # Run all tests
  only:
    - merge_requests # Run tests for merge requests

What this stage does:

  • Uses the same Docker image as the build stage.
  • Runs the mvn test command to validate our code.
  • Is configured to run for merge requests, since the main point of testing is to check code before it's merged into the main branch.

The deploy stage handles deploying the application. For starters we'll set up deployment to a staging environment.


deploy:
  stage: deploy
  image: docker:20.10.16 # Use Docker for deployment
  services:
    - docker:dind # Docker-in-Docker to work with containers
  script:
    - docker build -t my-spring-app:latest .
    - docker run -d -p 8080:8080 my-spring-app:latest
  only:
    - main # Deploy runs only for the main branch

Let's break down the details:

  • image and services: we're using Docker for deployment.
  • script: we build a Docker image of our app and run the container.
  • only: deploy happens only from the main branch.

Full pipeline example

Here's what the full .gitlab-ci.yml file looks like with all stages:


stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: maven:3.8.5-openjdk-17
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar
  only:
    - main

test:
  stage: test
  image: maven:3.8.5-openjdk-17
  script:
    - mvn test
  only:
    - merge_requests

deploy:
  stage: deploy
  image: docker:20.10.16
  services:
    - docker:dind
  script:
    - docker build -t my-spring-app:latest .
    - docker run -d -p 8080:8080 my-spring-app:latest
  only:
    - main

Now we've got a working pipeline that, step by step:

  1. Builds the application (build).
  2. Runs unit tests (test).
  3. Deploys the built app inside a container (deploy).

How to monitor the pipeline

After you commit changes in GitLab:

  1. Open the CI/CD → Pipelines tab.
  2. You'll see a list of running pipelines and their status (success, failed, running, etc.).
  3. If something went wrong, click the specific stage to view the execution logs.

Common errors and how to fix them

  • Error: "Docker daemon not available"
    Make sure you added docker:dind to the services section.
  • Build error: "Unable to find dependency"
    Check your pom.xml — maybe the dependency is specified incorrectly or there's no access to the Maven repositories.
  • Tests fail in the "test" stage
    Always run your tests locally before pushing to the repo.

Now you're ready to automate building, testing, and deploying your Spring Boot app with GitLab CI. By the way, don't let errors scare you. They're inevitable, but you can beat them.

Comments
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION