Автоматизація деплою сайту: налаштування 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 — і ваш деплой стане надійним та швидким.