In this lecture you'll learn how to:
- Create and configure a pipeline in GitLab CI for a Spring Boot application.
- Implement build, test, and deploy stages.
- 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:
build: building the project.test: testing (unit and/or integration tests).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 usingmvn clean packageto 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 testcommand 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:
imageandservices: 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:
- Builds the application (
build). - Runs unit tests (
test). - Deploys the built app inside a container (
deploy).
How to monitor the pipeline
After you commit changes in GitLab:
- Open the CI/CD → Pipelines tab.
- You'll see a list of running pipelines and their status (success, failed, running, etc.).
- 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 addeddocker:dindto theservicessection. - Build error: "Unable to find dependency"
Check yourpom.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.
GO TO FULL VERSION