«Правка уже готова, осталось выложить» может означать несколько разных вещей. Код написан, но ещё не объединён с другими изменениями. Приложение собрано, но не проверено. На сервере появилась новая версия, но форма перестала отправлять заявки. CI/CD помогает сделать этот путь видимым и повторяемым: команда знает, какая версия проходит проверки, почему процесс остановился и что именно можно выпустить.
В Гуси-Лебеди мы предлагаем разбирать автоматизацию на одном понятном изменении. Представим, что на сайте добавляют обязательное поле в форму обращения. Это условный пример для объяснения процесса, а не кейс компании. Проследим, что должно произойти до того, как новый вариант увидит посетитель.
CI, Continuous Integration, означает непрерывную интеграцию. Команда часто объединяет небольшие изменения кода, а сборки и автоматические проверки помогают находить проблемы при их совместной работе. Сохранение кода само по себе ещё не доказывает, что приложение собралось или работает правильно.
CD имеет два значения. При Continuous Delivery, непрерывной доставке, изменения проходят подготовку к выпуску, но решение об установке в рабочую среду принимает человек. При Continuous Deployment, непрерывном развёртывании, установка выполняется автоматически после предусмотренных успешных проверок. Поэтому ручное подтверждение релиза не означает, что автоматизации нет.
Эти различия описаны в документации Yandex Cloud. Ни один из подходов не отменяет выбора нужных испытаний, ответственности за выпуск и наблюдения за работающим продуктом.
Как описать этапы CI/CD и состав выпуска
В нашем примере разработчик меняет форму и сохраняет правку в системе контроля версий. Затем запускаются заранее настроенные задачи: подготовка приложения, проверка кода и тесты. Последовательность таких действий называют пайплайном, или конвейером. Отдельная задача может выполнять один шаг, например сборку или проверку обязательного поля. Условия запуска и перехода к следующему шагу задаёт команда.
Для формы важно проверить оба направления: корректно заполненная заявка проходит, а запрос без обязательного значения получает понятный отказ. Если проверка падает, процесс должен показать причину. Исправление проходит испытания снова. Отключать упавшую проверку ради зелёного статуса допустимо обсуждать только после выяснения, что именно сломалось и какую защиту команда теряет.
Результатом сборки может быть готовый пакет приложения или контейнерный образ. Такой сохраняемый результат называют артефактом. Его стоит связывать с конкретной версией исходного кода, чтобы отличать проверенный выпуск от другого, собранного позднее. Если после тестов приложение пересобрали в иных условиях, нужно выяснить, соответствует ли устанавливаемый результат тому, который проверяли.
На тестовом стенде команда проверяет весь сценарий формы: отображение поля, сообщение при ошибке, отправку и обработку корректной заявки. Здесь важно заранее обозначить границу проверки. Уведомление в тестовом почтовом ящике не подтверждает доставку в рабочую CRM. Для рабочей интеграции потребуется отдельная проверка в разрешённых условиях.
История изменений, ревью и выпуск связаны, но отвечают на разные вопросы. В статье о контроле версий в Git разбираем работу с исходным кодом. CI/CD продолжает этот путь: помогает получить известную сборку, проверить её и довести до нужного окружения.
Не обязательно сразу автоматизировать всё до установки на рабочий сайт. Начать можно с повторяемой сборки и важных проверок, затем добавить тестовую среду и управляемый выпуск. Состав процесса зависит от приложения и рисков изменения. У команды должна оставаться возможность объяснить каждый шаг и проверить его результат.
Какие проверки включать перед выпуском
У каждой проверки должен быть понятный вопрос. Можно ли собрать приложение из этой версии кода? Принимает ли обработчик корректно заполненную форму? Не пропускает ли он заявку без обязательного поля? Доходит ли отправленное обращение до нужного получателя? Один успешный ответ не заменяет остальные.
Для нашего примера проверку условия обязательности можно провести отдельно от внешней CRM. Так команда быстрее найдёт ошибку в собственной логике. Затем нужно испытать взаимодействие компонентов: интерфейс отправляет сведения, сервер понимает их, обработчик сохраняет нужные значения. Полный пользовательский сценарий проверяет уже всю цепочку в выбранной среде. Если внешнюю систему заменили тестовым ответом, это ограничение остаётся в результате испытания.
Автоматические тесты выполняют описанные командой действия и сравнения. Они не могут проверить требование, которое в них не заложили. Если поле появилось в форме, но не было передано в CRM, тест только на открытие страницы может завершиться успешно. Поэтому состав испытаний стоит связывать с тем, что меняется и что важно для пользователя.
Сборка приложения. Получается ли подготовить запускаемый результат. При этом такая проверка сама по себе не подтверждает: правильно ли обработана заявка.
Проверка правила формы. Принимаются ли допустимые значения и отклоняются ли недопустимые. При этом такая проверка сама по себе не подтверждает: доступна ли рабочая CRM.
Проверка взаимодействия. Правильно ли компоненты обмениваются нужными данными. При этом такая проверка сама по себе не подтверждает: корректность всех действий посетителя.
Пользовательский сценарий. Проходит ли выбранный путь от формы до ожидаемого результата. При этом такая проверка сама по себе не подтверждает: работу сценариев, которые не испытывали.
Часть проверки интерфейса может остаться ручной. Человек оценивает понятность сообщения, порядок действий и отображение поля на телефоне. Это можно включить в процесс выпуска, сохранив автоматическую сборку и тестирование. Автоматизация не требует объявлять любой ручной шаг ошибкой организации.
Отдельно согласуйте проверки зависимостей и обращения с секретами. Рабочие ключи не должны попадать в открытый исходный код и журналы выполнения. Задаче сборки нужны права для её работы, а не все полномочия администратора. Конкретные настройки зависят от платформы, размещения и правил проекта.
Когда проверка падает, сначала разберите отчёт. Причина может находиться в изменении приложения, тестовых данных, недоступном сервисе или самой среде выполнения. Повторный запуск без выяснения причины иногда даёт зелёный результат, но не объясняет исходный сбой. Запишите, что исправили и какая версия прошла испытания.
Как разделить среды и принять решение о релизе
Тестовая среда нужна, чтобы проверять изменения до их появления у посетителей. Но слово «тестовая» ещё не описывает её устройство. Уточните версию приложения, конфигурацию, подключённые сервисы и разрешённые данные. Сравните существенные условия с рабочей средой: успешный результат на другом окружении имеет границы.
В примере с формой стенд может отправлять заявки в тестовый ящик. Это разумный способ испытать уведомление, не создавая реальные обращения. Но рабочую CRM, её права и сопоставление полей он не проверяет. Перед выпуском команда должна знать, какой участок подтверждён, а где потребуется дополнительная проверка.
При непрерывной доставке назначенный человек разрешает выпуск подготовленной версии. Такое решение удобно, когда нужно согласовать время изменения, готовность сотрудников или связанные действия. При непрерывном развёртывании разрешение задают условия процесса, а установка проходит без отдельного ручного подтверждения. Выбирайте режим по требованиям проекта и качеству проверок.
Для выпуска назовите конкретный артефакт, результаты испытаний и действия с данными. Если новое поле требует изменения структуры базы, эти работы тоже входят в план. При обсуждении разработки серверной части веб-проекта полезно согласовать совместимость приложения и данных до настройки автоматической установки.
Для выполнения процесса нужны инструмент управления задачами и среда, где команды запускаются. Конфигурация описывает события запуска, последовательность действий и условия. Исполнитель получает исходный код, запускает сборку и тесты, сохраняет результат. Выбор конкретной платформы стоит начинать с требований: где хранится код, где можно выполнять задачи, кто обслуживает среду и какие доступы допустимы.
Не выбирайте систему по одному бесплатному тарифу. Посчитайте подготовку процесса, вычисления, хранение результатов, обслуживание и работу с изменениями. Ограничения конкретного сервиса нужно проверять в его действующих условиях. Название CI/CD не делает поддержку бесплатной и не задаёт одинаковую стоимость для всех проектов.
Как проверять результат и готовить восстановление
После установки нужно открыть обновлённый сайт и проверить то, ради чего выпускали изменение. В нашем примере это отображение нового поля, понятное сообщение при незаполненном значении и разрешённая отправка корректной заявки. Затем проверяют её обработку выбранной рабочей системой. Завершённое задание установки подтверждает свой шаг, но не всю эту цепочку.
У наблюдения должен быть ответственный. Заранее договоритесь, кто смотрит результат выпуска, где видит ошибки и при каком сигнале останавливает дальнейшие действия. Для формы таким сигналом может стать подтверждённая ошибка обработки обращения. Набор показателей и период наблюдения выбирают по конкретному сервису, а не по универсальной цифре.
Восстановление разберите до выпуска. Предыдущий пакет приложения помогает вернуть код, но не обязательно возвращает данные. Если обновление меняло структуру базы или уже отправило сведения во внешнюю систему, потребуется отдельный порядок действий. Не обещайте откат одной кнопкой, пока этот сценарий не испытан.
Для нашего условного изменения команда должна выяснить, сможет ли старая версия обработать новые записи. Если нет, простой возврат файлов может добавить другую ошибку. Возможность восстановления проверяют в разрешённой тестовой среде и фиксируют границы результата: что вернулось, какие данные сохранились и какие действия пришлось выполнить отдельно.
При передаче процесса следующему сотруднику нужны:
- связь версии кода, артефакта и установленного выпуска;
- описание этапов, условий остановки и результатов проверок;
- доступы компании и ответственные за среду выполнения;
- порядок выпуска и проверенный сценарий восстановления с ограничениями.
Документация полезна, когда помогает разобраться с реальной остановкой: где найти отчёт, какой пакет установлен и кто принимает решение. После изменения интеграции или окружения её нужно пересматривать вместе с проверками. Это стоит включать в сопровождение сайта с регулярными релизами.
Чтобы оценить пользу автоматизации, фиксируйте время от согласованного изменения до выпуска, продолжительность отдельных этапов и выпуски, после которых потребовалось исправление. Для сбоев записывайте момент обнаружения и восстановления работы. Сравнивайте одинаковые типы изменений и условия: ускорение сборки само по себе не подтверждает ускорение всего процесса. Такие наблюдения помогают выбирать следующий шаг, а не обещать универсальную экономию.
Для Гуси-Лебеди смысл CI/CD в том, чтобы сделать путь изменения понятным: известный код, проверенный результат сборки, согласованный выпуск и наблюдение за работающим сайтом. Начните с шага, который команда постоянно повторяет и может проверить. Добавляйте автоматизацию по мере готовности процесса, сохраняя ясную ответственность за результат.