Git, CI/CD и деплой без простоя

01Основы Git: коммиты, ветки, merge и rebase

Коммит — это снимок всего проекта плюс сообщение и указатель на родителя, так что история — это цепочка снимков. Ветка — просто подвижная метка, указывающая на коммит, поэтому ветки дешёвые. Когда две линии работы нужно свести вместе, вы делаете merge или rebase. Merge создаёт новый коммит с двумя родителями и сохраняет историю ровно такой, какой она была. Rebase переигрывает ваши коммиты поверх свежего main и даёт прямую линию, но переписывает эти коммиты с новыми хэшами. Правило: делайте rebase своей локальной или feature-ветки, чтобы навести порядок, но никогда не делайте rebase коммитов, которые другие уже стянули. Хорошие коммиты маленькие и сфокусированные, а их сообщение объясняет, зачем, а не только что.

1git switch -c feature/order-export
2git add -p                       # stage hunks, review as you go
3git commit -m "Add CSV export for orders"
4git fetch origin
5git rebase origin/main           # update your branch, resolve conflicts
6git push --force-with-lease      # safe force-push of your own branch
7git log --oneline --graph -15

02Стратегии ветвления: trunk-based и GitFlow

Trunk-based разработка держит одну основную ветку, которая всегда готова к релизу. Разработчики работают в короткоживущих ветках, которые в идеале вливаются за день-два, а незаконченные фичи прячут за feature flag'ами. Это сводит к минимуму болезненные мерджи и естественно сочетается с continuous deployment. GitFlow использует долгоживущие ветки develop и main плюс ветки feature, release и hotfix. Он подходит продуктам с версионированными релизами по расписанию — например, мобильным приложениям, проходящим ревью в сторах, или on-premise софту, где одновременно поддерживается несколько версий. Для большинства веб-приложений выигрывает trunk-based с короткими pull request'ами. Что бы вы ни выбрали, защитите main: требуйте pull request'ы, зелёные проверки и хотя бы одно ревью, запретите force-push.

• Trunk-based: короткие ветки, feature flag'и, деплой из main.
• GitFlow: ветки develop + release, хорош для версионированных релизов.
• Релизные теги (v1.8.0) точно отмечают, что ушло в продакшен.

03Pull request'ы и код-ревью

Pull request — это предложение влить ветку плюс обсуждение вокруг него. Его задача — ловить баги, делиться знаниями и поддерживать единообразие кодовой базы, а не показывать, кто тут сеньор. Держите pull request'ы маленькими, в идеале до нескольких сотен строк: качество ревью резко падает с ростом размера. В описании должно быть, что изменилось, зачем и как это проверялось, а для UI — скриншоты. Стиль и форматирование пусть проверяет автоматика, чтобы люди могли сосредоточиться на логике, сохранности данных, безопасности, именовании и недостающих тестах. Ревьюеры должны быть конкретными и доброжелательными и отделять блокирующие замечания от предложений. Файлы CODEOWNERS направляют изменения людям, которые знают эту часть кода, а обязательные status check'и не дают ничего влить, пока CI красный.

04Continuous integration: пайплайн на каждое изменение

Continuous integration означает, что каждый push и pull request автоматически собирается и тестируется в чистом окружении. Типичный пайплайн ставит зависимости из lockfile, запускает линтер и проверку типов, гоняет unit- и feature-тесты и собирает продакшен-артефакт. Располагайте шаги от быстрых к медленным, чтобы большинство ошибок всплывало за минуту-две. Кэшируйте загрузку зависимостей между запусками. Пайплайн должен быть одинаковым шлагбаумом для всех: если он красный, изменение не вливается. Ниже — минимальный workflow GitHub Actions для Node- или Next.js-проекта; GitLab CI, Bitbucket Pipelines и другие используют очень похожие идеи с другим синтаксисом. Секреты живут в хранилище секретов CI-провайдера и никогда — в репозитории.

1name: ci
2on:
3  pull_request:
4  push:
5    branches: [main]
6jobs:
7  check:
8    runs-on: ubuntu-latest
9    steps:
10      - uses: actions/checkout@v5
11      - uses: actions/setup-node@v5
12        with: { node-version: 24, cache: npm }
13      - run: npm ci
14      - run: npm run lint
15      - run: npx tsc --noEmit
16      - run: npm test
17      - run: npm run build

05Стратегии деплоя: rolling, blue-green, canary

Continuous delivery означает, что любую зелёную сборку можно задеплоить одной кнопкой; continuous deployment — что она деплоится автоматически. Важно и то, как вы заменяете работающую версию. Rolling deploy заменяет инстансы по одному за load balancer'ом: мощность слегка проседает, но сервис продолжает работать. Blue-green держит два одинаковых окружения: вы деплоите в простаивающее (green), проверяете его, затем переключаете трафик на балансировщике или симлинком — и обратное переключение мгновенно. Canary отправляет на новую версию небольшую долю трафика, скажем пять процентов, следит за ошибками и задержками и постепенно расширяет долю. На одном сервере идею blue-green обычно реализуют через папки релизов и атомарное переключение симлинка или через запуск нового контейнера, который проходит health check, прежде чем на него переключат proxy.

• Rolling: дёшево, постепенно, две версии работают одновременно.
• Blue-green: мгновенное переключение и мгновенный откат, ненадолго нужна двойная мощность.
• Canary: ограничивает радиус поражения, но нужны хорошие метрики, чтобы судить.

06Деплой без простоя для Laravel и Next.js

Для Laravel на VPS проверенный паттерн — атомарные релизы: каждый деплой уходит в новую папку с таймстемпом, общие .env и storage подключаются симлинками, там же ставятся зависимости и собираются кэши, и только потом симлинк current переключается одним атомарным шагом. Reload PHP-FPM очищает OPcache, а queue:restart говорит воркерам доделать текущую задачу и стартовать уже на новом коде. Для Next.js тоже собирайте в новую папку релиза, а затем плавно перезагружайте Node-процесс (pm2 reload в cluster-режиме запускает новые воркеры до остановки старых) или запускайте новый контейнер и переключайте proxy после того, как он прошёл health check. Остерегайтесь рассинхрона версий: браузеры со старой открытой страницей могут запрашивать старые JavaScript-чанки, поэтому какое-то время держите предыдущие статические ассеты доступными.

1#!/usr/bin/env bash
2set -euo pipefail
3APP=/var/www/app
4RELEASE=$APP/releases/$(date +%Y%m%d%H%M%S)
5git clone --depth 1 --branch main [email protected]:your_user/app.git "$RELEASE"
6cd "$RELEASE"
7rm -rf storage && ln -s $APP/shared/storage storage
8ln -s $APP/shared/.env .env
9composer install --no-dev --optimize-autoloader --no-interaction
10npm ci && npm run build
11php artisan migrate --force
12php artisan optimize
13ln -sfn "$RELEASE" $APP/current          # atomic switch
14sudo systemctl reload php8.3-fpm         # match your PHP version
15php artisan queue:restart

07Миграции базы данных и откаты

Код можно откатить за секунды, данные — нет. Во время любого деплоя старый и новый код какое-то мгновение работают одновременно, поэтому каждая миграция должна работать с обеими версиями. Паттерн expand and contract делает это безопасным. Чтобы переименовать колонку: сначала добавьте новую колонку и пишите в обе (expand), задеплойте, заполните старые строки пачками, переключите чтение на новую колонку и только в одном из следующих релизов удалите старую (contract). Избегайте долгих блокировок больших таблиц; добавляйте индексы конкурентно, если база это поддерживает. Откат — это повторный деплой предыдущей папки релиза или тега образа, поэтому держите несколько последних. Для базы данных лучше катиться вперёд исправляющей миграцией, чем запускать down-миграции в продакшене, и всегда имейте свежий бэкап перед рискованными изменениями.

• Сначала только добавление: новые колонки nullable или со значениями по умолчанию.
• Разрушающие изменения (удаление, переименование) — только когда старую структуру больше не использует никакой код.
• Держите на диске несколько предыдущих релизов для мгновенного отката.

08Как Git хранит вашу работу и почему почти ничего не теряется

Git — это база данных с адресацией по содержимому. Каждая версия файла хранится как blob, каждый каталог — как tree, перечисляющий blob'ы и другие tree, а каждый коммит — как объект, который указывает на один корневой tree, родительские коммиты, автора и сообщение. Имя каждого объекта — хэш его содержимого, поэтому одинаковые файлы хранятся один раз, а любая подмена меняет хэш. Ветки и теги — это ref'ы: маленькие файлы с одним хэшем коммита. HEAD указывает на ref, на котором вы сейчас находитесь. Поскольку коммиты никогда не редактируются, а только создаются новые, rebase или reset не уничтожают старые коммиты — они просто теряют свою метку. Reflog записывает каждое положение HEAD и каждой ветки, обычно примерно за 90 дней, так что после неудачного rebase или reset можно найти старый хэш и снова направить на него ветку. Garbage collection удаляет недостижимые объекты только после этого срока.

1git reflog -15                      # where HEAD has been
2git branch rescue HEAD@{3}          # recover the state from 3 moves ago
3git reset --hard ORIG_HEAD          # undo the last rebase or merge
4git fsck --lost-found               # find dangling commits and blobs
5git cat-file -p HEAD                # see a commit object: tree, parent, author

09Защита самого пайплайна

CI-система держит ключи от продакшена, поэтому атакуют именно её. Важнее всего четыре меры. Первая — минимальные права для токена джоба: явно объявляйте permissions в начале каждого workflow, по умолчанию только чтение. Вторая — полностью откажитесь от долгоживущих облачных ключей: GitHub Actions, GitLab и другие умеют выдавать короткоживущий OIDC-токен, который AWS, Google Cloud или Azure обменивают на временные учётные данные, ограниченные одним репозиторием и веткой. Третья — фиксируйте сторонние actions на полный SHA коммита, а не на тег, потому что тег может передвинуть любой, кто контролирует тот репозиторий. Четвёртая — осторожнее с workflow, которые запускаются pull request'ами из форков: pull_request_target выполняется с секретами базового репозитория, поэтому он никогда не должен делать checkout и запускать недоверенный код. Деплой в продакшен должен идти через защищённое окружение с обязательными ревьюерами, чтобы скомпрометированная ветка не могла задеплоить сама.

1permissions:
2  contents: read
3  id-token: write          # allow OIDC token for cloud login
4jobs:
5  deploy:
6    environment: production  # required reviewers + env-scoped secrets
7    runs-on: ubuntu-latest
8    steps:
9      - uses: actions/checkout@v5
10      - uses: aws-actions/configure-aws-credentials@v6
11        with:
12          role-to-assume: arn:aws:iam::111122223333:role/deploy-web
13          aws-region: eu-central-1

10Собирать один раз, продвигать по digest и выстраивать деплои в очередь

Зрелый пайплайн собирает артефакт ровно один раз — при merge в main, помечает его SHA коммита и пушит в registry. Staging и продакшен затем деплоят тот же самый артефакт, определяемый неизменяемым digest, так что протестированное байт в байт совпадает с выкаченным. Пересборка для продакшена снова вносит риск: за это время могли поменяться зависимость или базовый образ. Два одновременных деплоя могут оставить сервер наполовину на каждой версии, поэтому выстраивайте их в очередь через concurrency group и не отменяйте уже идущий деплой: прерваться на середине хуже, чем довести до конца. Записывайте каждый деплой с коммитом, временем и автором, чтобы на вопрос «что сейчас крутится в продакшене» был ответ в одну строку. Откат тогда — это просто повторный деплой предыдущего digest.

1concurrency:
2  group: deploy-production
3  cancel-in-progress: false     # queue, never kill a running deploy
4 
5# build stage (once):
6#   docker build -t registry.example.com/web:$GITHUB_SHA .
7#   docker push registry.example.com/web:$GITHUB_SHA
8# deploy stages reuse the same tag/digest, no rebuild

11Изменения схемы на больших таблицах без блокировки сайта

Expand and contract сохраняет совместимость кода и схемы, но каждый шаг всё равно может заблокировать таблицу. В PostgreSQL большинство форм ALTER TABLE берут блокировку ACCESS EXCLUSIVE. Даже быстрое изменение должно дождаться окончания любой долгой транзакции, а пока оно ждёт, все новые запросы к этой таблице встают в очередь за ним — и миграция на две миллисекунды может заморозить сайт на минуты. Защищайтесь коротким lock_timeout и повторами. Индексы стройте через CREATE INDEX CONCURRENTLY: он не блокирует запись, но не может выполняться внутри транзакции, поэтому во фреймворках, которые оборачивают миграции в транзакции, для такой миграции это нужно отключить (в Laravel — выставить свойство миграции withinTransaction в false). Добавлять NOT NULL на огромную таблицу безопаснее как CHECK-ограничение с NOT VALID и последующей валидацией. В MySQL предпочитайте ALGORITHM=INSTANT, где он поддерживается, или инструменты вроде gh-ost для больших перестроений.

1SET lock_timeout = '3s';
2ALTER TABLE orders ADD COLUMN export_status text;   -- metadata-only, fast
3 
4CREATE INDEX CONCURRENTLY idx_orders_export_status
5  ON orders (export_status);
6 
7ALTER TABLE orders ADD CONSTRAINT orders_export_status_nn
8  CHECK (export_status IS NOT NULL) NOT VALID;
9ALTER TABLE orders VALIDATE CONSTRAINT orders_export_status_nn;