Контроль версий и деплой: как безопасно выкатывать изменения

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

Что такое контроль версий простыми словами

Система контроля версий — это журнал всех изменений в коде сайта. Стандарт индустрии — Git. Каждое изменение сохраняется как отдельная запись, коммит: кто изменил, когда, какие строки и с каким комментарием. Код хранится в репозитории — на сервисе вроде GitLab или в собственном хранилище студии, и у каждого разработчика есть его полная копия.

Для заказчика это означает три практические вещи. Первое — ничего не теряется: можно посмотреть, как выглядел любой файл месяц или полгода назад. Второе — понятно, кто и что делал: если на сайте появилась ошибка, за пару минут находится изменение, которое её вызвало. Третье — несколько человек могут работать параллельно, не затирая правки друг друга. Без Git двое разработчиков, правящих один файл по FTP, рано или поздно уничтожат работу друг друга, и никто этого сразу не заметит.

Важно: в репозитории хранится код и конфигурация, но не загруженные пользователями файлы и не база данных. Картинки товаров, заказы, тексты страниц из админки живут отдельно и защищаются резервным копированием. Это разные инструменты для разных задач, и один не заменяет другой.

Ветки: как вести несколько задач одновременно

Git позволяет создавать ветки — параллельные линии разработки. Основная ветка соответствует тому, что сейчас работает на сайте. Новая функция, например интеграция с новой службой доставки, разрабатывается в отдельной ветке. Пока она не готова и не проверена, основной код её не видит, и срочную правку опечатки в шапке можно выпустить, не дожидаясь, пока закончат большую задачу.

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

Окружения: локальное, тестовое, рабочее

Безопасный процесс строится на разделении окружений. Это несколько копий сайта, каждая со своей ролью. Изменение проходит их последовательно и попадает к покупателям только после того, как проверено на предыдущих этапах.

Ключевое требование к тестовому окружению — оно должно максимально повторять рабочее: та же версия PHP и базы данных, те же модули сервера, похожий объём данных. Если на тестовом сервере 50 товаров, а на рабочем 40 000, проблема с медленным фильтром проявится только у покупателей. Тестовый сайт обязательно закрывается от индексации и паролем, иначе поисковые системы найдут дубль и начнут путаться, какая версия основная.

Отдельный вопрос — персональные данные. Копируя рабочую базу на тестовый сервер, мы заменяем имена, телефоны и адреса покупателей на фиктивные. Это требование 152-ФЗ «О персональных данных» и просто здравый смысл: тестовый сервер обычно защищён слабее рабочего.

Как проходит деплой

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

Правильный деплой атомарный. Новая версия целиком собирается в отдельной папке на сервере, туда устанавливаются зависимости, собираются стили и скрипты, применяются миграции базы данных. Только когда всё готово, символическая ссылка «текущая версия» мгновенно переключается на новую папку. Предыдущие несколько версий остаются на диске, поэтому откат — это то же переключение ссылки обратно.

1. Слияние в основную ветку

   После ревью и проверки на тестовом сервере изменения вливаются в основную ветку репозитория.

2. Автоматические проверки

   Система непрерывной интеграции запускает тесты, проверку стиля кода и сборку. Если что-то не проходит, выпуск блокируется.

3. Сборка новой версии

   На сервере создаётся отдельная папка релиза, куда разворачивается код, зависимости и собранный фронтенд.

4. Миграции базы данных

   Изменения структуры таблиц применяются скриптами, записанными в репозитории, а не руками через панель управления.

5. Переключение и прогрев

   Рабочая версия переключается на новый релиз, сбрасывается и прогревается кеш, перезапускаются фоновые обработчики.

6. Проверка после выпуска

   Автоматический и ручной дымовой тест ключевых сценариев, контроль журнала ошибок в первые полчаса.

Весь процесс запускается одной командой или кнопкой и занимает от одной до пяти минут. Время простоя для посетителей — ноль.

Миграции и база данных — самое уязвимое место

Код откатить легко, а данные — нет. Если новая версия переименовала колонку в таблице заказов и за десять минут работы в неё записалось сто новых заказов, простое возвращение старого кода сломает сайт: старый код будет искать колонку со старым именем. Поэтому изменения базы мы проектируем так, чтобы старая и новая версии кода могли работать с ней одновременно.

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

Особая история — CMS вроде WordPress и 1С-Битрикс, где часть настроек хранится в базе, а не в коде: структура инфоблоков, свойства товаров, настройки модулей. Такие изменения мы тоже оформляем миграциями в репозитории, а не «накликиваем» в админке рабочего сайта. Иначе тестовый и рабочий сайты постепенно расходятся, и через полгода никто не может сказать, чем они отличаются.

Когда и как выкатывать обновления

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

Лучше выпускать часто и маленькими порциями, чем редко и большими. Релиз из трёх изменений легко проверить и, если что-то пошло не так, легко понять причину. Релиз из сорока изменений, накопленных за два месяца, почти гарантированно принесёт сюрпризы, и искать виновника придётся долго. Для рискованных функций используем флаги: код выкатывается выключенным, а потом функция включается в админке сначала для сотрудников, затем для части посетителей.

Что делать, если что-то сломалось

Первое правило — сначала откатить, потом разбираться. Пока сайт работает с ошибкой, бизнес теряет деньги, а поиск причины может занять час. Откат на предыдущую версию занимает минуту, и уже в спокойном режиме ошибка воспроизводится на тестовом сервере, исправляется и выпускается заново. Мониторинг ошибок, подключённый к сайту, обычно сообщает о проблеме раньше, чем звонит первый покупатель.

Что требовать от подрядчика

Заказчику не обязательно разбираться в Git, но стоит задать подрядчику несколько вопросов. Ответы на них быстро покажут уровень зрелости команды и то, насколько защищён ваш сайт от случайных поломок.

• Код сайта хранится в репозитории, и у компании-владельца есть к нему доступ.
• Есть тестовая копия сайта, где проверяются изменения перед выпуском.
• Правки на рабочем сервере напрямую не вносятся, все изменения идут через репозиторий.
• Выкатка автоматизирована, и предусмотрен откат на предыдущую версию.
• Пароли и ключи доступа не хранятся в коде, а лежат в настройках окружения.
• После выпуска проверяются ключевые сценарии и журнал ошибок.
• При смене подрядчика вы получаете репозиторий с полной историей изменений.

Последний пункт особенно важен. Репозиторий — это актив компании. Если он хранится только в личном аккаунте фрилансера, при расставании вы рискуете получить архив файлов без истории и без понимания, что и зачем в нём менялось. Мы при запуске передаём заказчику доступ к репозиторию, а в рамках технической поддержки продолжаем работать в том же процессе: каждая задача — отдельная ветка, проверка на тестовом сервере, выпуск с возможностью отката.

Итоги

Контроль версий и выстроенный деплой — не излишество для крупных проектов, а базовая гигиена любого сайта, который приносит деньги. Git хранит историю и позволяет команде работать параллельно, разделение окружений не пускает непроверенный код к покупателям, автоматический атомарный деплой убирает человеческий фактор и простой, а продуманные миграции защищают данные при откате.

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