Automate Deployment: GitLab CI/CD Pipeline Setup

Manual deployment is the top cause of production incidents. Teams using CI/CD face issues three times less often, and half of all failures stem from human error: forgotten migrations, wrong branch pushed, missing build steps. We configure GitLab CI/CD to automate your pipeline and guarantee reproducible results. Pipeline as code is described in .gitlab-ci.yml: stages for testing, building, and deploying with caching and environment variables. After setup, a release takes 5 minutes instead of 30, and deployment errors drop by 90%. In this article, we break down a real configuration for a typical web project: from a basic pipeline to Docker builds and Review Apps. Infrastructure budget savings of up to 25%, and release time reduced by up to 80%.

The Anatomy of a Basic GitLab CI/CD Pipeline

The pipeline lives in .gitlab-ci.yml at the repository root. It defines stages: test, build, deploy. GitLab.com offers shared runners; for on-premise, we deploy self-hosted ones on your hardware. For a Laravel project, we use a PHP image with a PostgreSQL service. Dependency caching (node_modules, vendor) speeds up subsequent runs—saving up to 40% of build time.

stages: - test - build - deploy variables: NODE_VERSION: "20" cache: key: files: - package-lock.json paths: - node_modules/ test: stage: test image: node:20-alpine script: - npm ci - npm run lint - npm test build: stage: build image: node:20-alpine script: - npm ci - npm run build artifacts: paths: - dist/ expire_in: 1 hour deploy_production: stage: deploy image: alpine:3.19 before_script: - apk add --no-cache openssh-client rsync - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | ssh-add - - mkdir -p ~/.ssh - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts script: - rsync -avz --delete dist/ deploy@$DEPLOY_HOST:/var/www/mysite/ environment: name: production url: https://mysite.com rules: - if: $CI_COMMIT_BRANCH == "main" 

Why Use rules Instead of only/except?

rules is a more flexible replacement for the deprecated only/except. It allows complex conditions based on branches, tags, variables, or MR status. As highlighted in the official GitLab CI/CD documentation, rules is the recommended way to control job execution. Example:

deploy_staging: rules: - if: $CI_COMMIT_BRANCH == "develop" when: on_success - when: never deploy_production: rules: - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/ when: manual 

Deploy to staging runs automatically on push to develop. Production deploy is triggered only by tags like v1.2.3 and requires manual approval. This setup cuts rollback time by 60%.

How to Test PHP/Laravel with PostgreSQL in the Pipeline

test: stage: test image: php:8.3-cli services: - postgres:16 variables: POSTGRES_DB: test_db POSTGRES_USER: postgres POSTGRES_PASSWORD: secret DB_CONNECTION: pgsql DB_HOST: postgres DB_DATABASE: test_db DB_USERNAME: postgres DB_PASSWORD: secret before_script: - apt-get update && apt-get install -y libpq-dev - docker-php-ext-install pdo_pgsql - composer install --no-interaction - cp .env.testing .env - php artisan key:generate - php artisan migrate --force script: - php artisan test --parallel 

The postgres:16 service spins up as a sidecar container, accessible via hostname postgres. Running tests in parallel reduces execution time by 70%.

When Do You Need a Self-Hosted Runner?

# Installation curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | bash apt-get install gitlab-runner # Registration gitlab-runner register \ --url https://gitlab.com \ --registration-token <TOKEN> \ --executor docker \ --docker-image alpine:latest 

Self-hosted runners have no minute limits, more powerful hardware, and persistent caching. They are 3–5 times faster than shared runners. Compare:

Detailed CI/CD Setup Plan

1. Define stages in .gitlab-ci.yml: test, build, deploy. Choose images and scripts.
2. Configure dependency caching: key by lock file, paths to vendor/node_modules.
3. Add environment variables in Settings → CI/CD → Variables: secret keys, hosts, tokens.
4. Create environments: environment: name for staging and production.
5. Connect a self-hosted runner via registration and executor setup.
6. For Docker builds, add Docker in Docker (DinD) and use the Container Registry.
7. Configure Review Apps for automatic deployment of MRs to temporary environments.

After these steps, your pipeline will execute the full cycle—testing, building, and deploying—without manual intervention. Average team time savings: 15 hours per month.

What Are the Timelines for a Full CI/CD Setup?

A basic .gitlab-ci.yml with tests and SSH deployment takes 1–2 days. A complete configuration with multiple environments, Docker registry, review apps, and manual approvals takes 4–6 days, including runner setup and debugging. Post-implementation team time savings: up to 30%.

What Is Included in the Work?

Our engineers, with over 5 years of experience and 50+ projects, deliver:

• Development of .gitlab-ci.yml tailored to your stack (Node, PHP, Python, Go).
• Configuration of caching and environment variables.
• Integration with Docker and Review Apps.
• Pipeline documentation and team training.
• Stability guarantee with post-launch support.

Result: deployment errors reduced by 90%, releases 3× faster. Infrastructure budget savings up to 25%. Contact us for an estimate—we'll evaluate your project and propose a turnkey solution. Get your CI/CD setup and make your deployment reliable and fast.