Getting Started with GitLab CI/CD: Pipelines, Runners, and SSH Deployment

The purpose of this guide is to give a friendly, hands‑on introduction to GitLab CI/CD through a sample application, allowing newcomers to start using pipelines without reading the entire GitLab documentation.

Pipeline Basics

Continuous Integration works by pushing small code commits to a Git repository; each push triggers a scripted pipeline that builds, tests, and validates the changes before merging into the main branch. Continuous Delivery/Deployment extends this by automatically deploying to production after each successful push to the default branch.

GitLab CI/CD relies on a single .gitlab-ci.yml file placed at the repository root. The file defines jobs that are grouped into a pipeline . Jobs are organized into stages , and the order of execution follows the stages list.

Example Pipeline Configuration

stages:
- build
- test
- deploy
image: alpine
build_a:
stage: build
script:
- echo "This job builds something."
build_b:
stage: build
script:
- echo "This job builds something else."
test_a:
stage: test
script:
- echo "This job tests something. It will only run when all jobs in the"
- echo "build stage are complete."
test_b:
stage: test
script:
- echo "This job tests something else. It will only run when all jobs in the"
- echo "build stage are complete too. It will start at about the same time as test_a."
deploy_a:
stage: deploy
script:
- echo "This job deploys something. It will only run when all jobs in the"
- echo "test stage complete."
deploy_b:
stage: deploy
script:
- echo "This job deploys something else. It will only run when all jobs in the"
- echo "test stage complete. It will start at about the same time as deploy_a."

The three stages—build, test, and deploy—contain the jobs shown in brackets: {build_a, build_b}, {test_a, test_b}, {deploy_a, deploy_b}. Jobs run in the order defined by the stages keyword.

You can use the only keyword to restrict jobs to specific branches, for example deploying to a staging server on one branch and to production on master :

deploy-production:
stage: deploy
script:
- ./deploy_prod.sh
only:
- master

GitLab Runner

GitLab Runner is an open‑source agent that executes the jobs defined in the pipeline and reports results back to GitLab. It runs on Linux, macOS, FreeBSD, and Windows, and can be installed via Docker, binary download, or package managers.

When using Docker, ensure Docker is installed and run the runner container, for example:

docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register

During registration you provide the GitLab URL and a registration token, after which the runner writes its configuration to the mounted volume.

SSH‑Based Deployment

To deploy code from a CI/CD job to a private server, add an SSH key pair to the runner. Generate a key with:

ssh-keygen -t rsa -b 4096 -C "example"

Copy the public key to authorized_keys on the target server and store the private key in a GitLab CI/CD variable (e.g., SSH_PRIVATE_KEY ). Then, in the pipeline, install the SSH client, add the key to the agent, and run the deployment command:

deploy_production:
stage: deploy
before_script:
- apk add openssh-client
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
script:
- ssh -o StrictHostKeyChecking=no username@host_ip_address "cd /project && git pull"
only:
- master

Because the Alpine base image does not include an SSH client, the pipeline explicitly installs it. Adjust the commands if you use a different base image.

The article concludes with links to historical posts, author information, and promotional material for a DevOps pipeline course.