CI/CD: как я перестал деплоить руками и начал жить спокойно

Деплой вручную — это как готовить ужин с закрытыми глазами. Да, ты можешь не обжечься. Но однажды ты точно отрежешь палец. Или подожжешь кухню.

Помню свои первые деплои. Это был ритуал, достойный шамана с бубном:

1. Залить код по FTP. 2. Зайти на сервер. 3. Перезапустить Node.js. 4. Молиться, чтобы ничего не упало. 5. Проверить руками — всё ли работает. 6. Обнаружить, что сломалось. 7. Откатить. 8. Начать заново.

Это занимало часы. Это было больно. Это было страшно. Но я думал, что так и надо.

Спойлер: не надо.

Боль ручного деплоя

Ручной деплой — это не просто «неудобно». Это опасно. Это дорого. Это убивает твою репутацию.

Вот что происходит, когда ты деплоишь руками:

1. Человеческий фактор. Забыл перезапустить сервер — релиз не вышел. Забыл обновить переменные окружения — всё упало. Не ту ветку залил — фича превратилась в баг.

2. Время простоя. Пока ты копируешь файлы, сервер живёт в промежуточном состоянии. Часть кода уже новая, часть — старая. Пользователи падают в ошибки. Ты в панике.

3. Отсутствие истории. Что изменилось? Какая версия на сервере? Кто и когда деплоил? Ответы: «не помню», «не знаю», «кажется, я».

4. Страх перед релизом. Чем сложнее система, тем страшнее деплоить. Ты начинаешь копить изменения, чтобы деплоить раз в месяц. Каждый релиз — это экстрим.

5. Невозможность отката. Что-то сломалось? Верни как было. А как было? Где тот код? Кто его помнит?

Я прошёл через всё это. И однажды сказал себе: «Хватит».

Что такое CI/CD и почему это не страшно

CI/CD — это не хайп. Это методология, которая превращает ад деплоев в предсказуемый процесс.

CI (Continuous Integration) — непрерывная интеграция

Каждый раз, когда ты пушишь код в репозиторий, автоматически:

- собирается проект; - запускаются тесты;CI/CD на практике: зачем уходить от ручного деплоя, как настроить GitHub Actions и что даёт автоматизация релизов разработчику. - проверяется стиль кода; - если всё ок — код готов к деплою.

CD (Continuous Delivery / Deployment) — непрерывная доставка

- Delivery — код автоматически собирается и готов к деплою, но релиз запускается вручную (нажал кнопку — покатилось). - Deployment — код автоматически деплоится в продакшн без участия человека (каждый пуш → новый релиз).

Я использую Continuous Delivery. Потому что я хочу контролировать момент релиза, но не хочу делать всю рутину руками.

Как я настроил свой CI/CD

Шаг 1. Репозиторий и ветки

У меня простая, но эффективная модель:

| Ветка | Назначение | |--------|------------| | main | всегда продакшн. Никто не пушит в main напрямую | | dev | разработка. Сюда мержатся фичи | | feature/ | ветки для новых фич | | hotfix/ | ветки для срочных исправлений |

Шаг 2. GitHub Actions — мой робот-деплой

Я использую GitHub Actions. Бесплатно, просто, интегрировано с репозиторием.

Мой пайплайн выглядит так:

yaml name: CI/CD Pipeline

on: push: branches: [ main, dev ] pullrequest: branches: [ main ]

jobs: test: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3

- name: Setup Node.js uses: actions/setup-node@v3 with: node-version: '18'

- name: Install dependencies run: npm ci

- name: Run tests run: npm test

- name: Lint run: npm run lint

- name: Build run: npm run build

deploy: needs: test runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' steps: - name: Checkout code uses: actions/checkout@v3

- name: Deploy to server uses: appleboy/ssh-action@v0.1.5 with: host: ${{ secrets.SERVERHOST }} username: ${{ secrets.SERVERUSER }} key: ${{ secrets.SERVERSSHKEY }} port: ${{ secrets.SERVERPORT }} script: | cd /var/www/app git pull origin main npm ci --production npm run build pm2 restart app pm2 save

Что здесь происходит:

1. Каждый пуш в main или dev запускает пайплайн. 2. Сначала — тесты. Если тесты упали — дальше никто не идёт. 3. Потом — сборка. Если сборка упала — дальше никто не идёт. 4. Если всё ок и это ветка main — деплой на сервер.

Это занимает 2–3 минуты. Без моего участия.

Что мне дал CI/CD

- Я перестал бояться деплоя. Теперь это 3 минуты спокойствия, а не 3 часа нервов. - У меня появилась история изменений. Каждый деплой — это конкретный коммит. Если что-то сломалось — я знаю, кто, когда и зачем это сделал. - Тесты ловят ошибки до продакшена. Упал тест — релиз не пошёл. Просто и надёжно. - Я могу деплоить несколько раз в день. Нет нужды копить изменения. Хочешь выпустить фичу — выпускай. - Откат — за 5 секунд. git revert → пуш → пайплайн → продакшен. Всё автоматом. - Я сплю спокойно. Сервер перезапускается сам. Я не должен просыпаться в 3 часа ночи, чтобы «починить деплой».

Что я понял за время настройки

CI/CD — это не про технологии. Это про культуру

Можно настроить GitHub Actions, GitLab CI, Jenkins — неважно. Важно изменить подход. Ты больше не думаешь «как я залью код». Ты думаешь «код сам зальётся, если тесты пройдут».

Тесты — это не опция. Это условие деплоя

Если у тебя нет тестов — CI/CD бесполезен. Тесты — это страховка. Если ты деплоишь без тестов — ты играешь в русскую рулетку.

Деплой без даунтайма — это следующий уровень

git pull + pm2 restart — это уже хорошо. Но если у тебя 10 000 пользователей — перезапуск заметят. Для этого нужны zero-downtime деплои (синие/зелёные деплои или балансировка). Это тема для отдельного поста.

Секреты — в переменных окружения

Никаких паролей в коде. Только secrets в GitHub Actions и .env на сервере. Если ты коммитишь пароль — ты уже проиграл.

Итог

CI/CD — это не про «хочу как у больших дядек». Это про твой сон, нервы и время.

Если ты до сих пор деплоишь руками — остановись. Прямо сейчас. Настрой простой пайплайн. Это займёт полдня. А сэкономит недели жизни.

Раньше я боялся релизов. Теперь я люблю их. Каждый пуш — это маленький праздник. Потому что я знаю: если что-то сломается — система скажет мне об этом до того, как увидят пользователи.

Автоматизируй то, что можно автоматизировать. Оставь себе то, что требует мышления.