Автоматизація деплою сайту: налаштування GitLab CI/CD пайплайну

Ручний деплой — головне джерело production-інцидентів. Команди з CI/CD стикаються з проблемами в 3 рази рідше, а кожен другий збій викликаний людським фактором: забули запустити міграції, не ту гілку залили, пропустили збірку. Ми налаштовуємо GitLab CI/CD, щоб автоматизувати pipeline і гарантувати відтворюваний результат. Pipeline як код описується в .gitlab-ci.yml: стадії тестування, збірки та деплою з кешуванням і змінними оточення. Після налаштування реліз займає 5 хвилин замість 30, а кількість помилок деплою знижується на 90%. У цій статті розберемо реальну конфігурацію для типового веб-проєкту: від базового пайплайну до Docker-збірки та Review Apps. Економія бюджету на інфраструктурі — до 25%, а скорочення часу релізів — до 80%.

Як виглядає базовий пайплайн в GitLab CI/CD?

Pipeline описується в .gitlab-ci.yml в корені репозиторію. В ньому визначаються стадії: test, build, deploy. GitLab.com надає shared runners; для on-premise підіймаємо self-hosted на вашому залізі. Наприклад, в проєкті на Laravel ми використовуємо PHP-образ з PostgreSQL сервісом. Кешування залежностей (node_modules, vendor) прискорює наступні запуски — економиться до 40% часу збірки.

---
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"

Чому варто використовувати rules замість only/except?

rules — більш гнучка заміна застарілому only/except. Дозволяє задавати складні умови: за гілками, тегами, змінними, статусом MR. Як зазначає офіційна документація GitLab CI/CD, rules — рекомендований спосіб керування виконанням джоб. Приклад:

---
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

Деплой на staging — автоматично при пуші в develop. Деплой на prod — тільки за тегом виду v1.2.3 та після ручного схвалення. Таке налаштування скорочує час на відкати на 60%.

Як протестувати PHP/Laravel з PostgreSQL в пайплайні?

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 

Сервіс postgres:16 підіймається як sidecar-контейнер, доступний за хостнеймом postgres. Запуск тестів у паралельних процесах скорочує час виконання на 70%.

Коли потрібен self-hosted runner?

# Встановлення curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | bash
apt-get install gitlab-runner
# Реєстрація
gitlab-runner register \
  --url https://gitlab.com \
  --registration-token <TOKEN> \
  --executor docker \
  --docker-image alpine:latest

Self-hosted раннер — без лімітів на хвилини, потужніше залізо, постійний кеш. Self-hosted раннери швидші за shared в 3–5 разів. У таблиці порівняємо підходи:

Детальний план налаштування CI/CD

1. Визначте стадії: test, build, deploy — в .gitlab-ci.yml. Вкажіть образи та скрипти.
2. Налаштуйте кешування залежностей: ключ за lock-файлом, шляхи до vendor/node_modules.
3. Додайте змінні оточення в Settings → CI/CD → Variables: секретні ключі, хости, токени.
4. Створіть оточення: environment: name для staging та production.
5. Підключіть self-hosted раннер через реєстрацію та налаштування executor.
6. Для Docker-збірки додайте DinD (Docker in Docker) та використовуйте Container Registry.
7. Налаштуйте Review Apps для автоматичного деплою MR на тимчасові оточення.

Після цих кроків ваш пайплайн виконуватиме повний цикл: тестування, збірку та деплой без ручних операцій. Середня економія часу команди — 15 годин на місяць.

Які терміни налаштування повноцінного CI/CD?

Базовий .gitlab-ci.yml з тестами та SSH-деплоєм — 1–2 дні. Повна конфігурація з кількома оточеннями, Docker registry, review apps, ручними схваленнями — 4–6 днів, включаючи налаштування раннерів та відлагодження. Економія часу команди після впровадження — до 30%.

Що входить в роботу?

Наші інженери з досвідом понад 5 років налаштовують CI/CD для 50+ проєктів. Включено:

• Розробка .gitlab-ci.yml під ваш стек (Node, PHP, Python, Go).
• Налаштування кешування та змінних оточення.
• Інтеграція з Docker та Review Apps.
• Документація пайплайну та навчання команди.
• Гарантія стабільної роботи — підтримка після запуску.

Результат: знижуємо кількість помилок деплою на 90% та прискорюємо релізи в 3 рази. Економія бюджету на інфраструктурі — до 25%. Зв'яжіться з нами для розрахунку — оцінимо ваш проєкт та запропонуємо рішення під ключ. Замовте налаштування CI/CD — і ваш деплой стане надійним та швидким.