Хардкодинг PRO - Гайд №16 - Автопроверки и выпуск версий (CI/CD) для новичка

СНАЧАЛА СМЫСЛ

Почему этот гайд вообще нужен

AI-кодеры сделали разработку намного быстрее. Но скорость без контроля означает, что ИИ может быстрее не только создать функцию, но и быстрее сломать рабочий сервис.

Главная ошибка новичка: «ИИ написал код, значит проект готов».

Нет. Между кодом и реальным пользователем должен появиться коридор проверок. Именно этот коридор и строит CI/CD.

Без CI/CD код может напрямую прилететь на сервер и сломать production

До CI/CD

Тыставишь задачу

AIменяет код

VPSобновляем руками

Рабочая версиянадеемся, что жив

😅если сломалось - разбираемся

После CI/CD

AIсоздаёт изменение

GitHubфиксирует версию

CIавтоматически проверяет

Публикациядоставляет проверенную версию

Наблюдениепроверяет реальность

Цель этого гайда не научить тебя писать YAML руками. Цель - дать ментальную модель: что должно произойти, в каком порядке и чем доказать, что всё реально работает.

НУЛЕВОЙ ЭТАЖ

GitHub с нуля: что с чем связано

Перед CI/CD нужно перестать воспринимать GitHub как «сайт, куда мы куда-то пушим код». GitHub в нашем процессе становится центральной системой управления версиями и автоматизацией.

Карта GitHub для новичка: Repository → Branch → Commit → Pull Request → Actions

Repository = папка проекта в GitHub

Repository, или repo, хранит код, историю изменений, тесты, документацию и настройки автоматизации.

Где увидеть: главная страница конкретного проекта на GitHub.

Commit = сохранённая точка истории

Как сохранение в игре. После полезного изменения мы фиксируем состояние. У commit есть уникальный идентификатор, например a81f94c.

Зачем: можно точно сказать, какая версия работала вчера и какая стоит сейчас.

Branch = отдельная ветка изменений

main обычно хранит стабильную основу. Новую функцию лучше делать в отдельной ветке, например feature/pdf-upload.

Зачем: ИИ может экспериментировать, не ломая основную версию.

Pull Request = предложение добавить изменения

Pull Request, сокращённо PR, показывает, что именно изменилось, какие файлы затронуты и прошли ли проверки.

Зачем: это естественная точка, где CI может автоматически проверить работу ИИ-кодера до merge.

Merge = объединить изменения

Если PR прошёл проверки, изменения из рабочей ветки объединяются с main.

Важно про «GitHub Missions».

В базовой CI/CD-схеме такого основного элемента нет. Скорее всего, речь про GitHub Environments. Ниже разберём их отдельно: staging и production.

ДВЕ АББРЕВИАТУРЫ

CI и CD простыми словами

CI: автоматическая проверка изменений

По-человечески: автоматическая проверка изменений.

ИИ изменил код. GitHub автоматически устанавливает проект, запускает нужные тесты, проверяет build. Если что-то не прошло - дальше не едем.

CI отвечает на вопрос: можно ли вообще принимать этот код?

CD: автоматическая доставка или публикация версии

Continuous Delivery - система автоматически готовит рабочую версию, но рабочая версия может требовать подтверждения человека.

Автоматическая публикация (Continuous Deployment) - после успешных проверок новая версия автоматически попадает пользователям.

Для новичка и коммерческого ИИ-проекта безопасная база: автоматический CI + контролируемый production deploy.

Аналогия с рестораном.

AI - повар. CI - контроль качества. CD - официант, который относит готовое блюдо клиенту. Сырое блюдо контроль не выпускает.

АВТОМАТИЗАЦИЯ ВНУТРИ GITHUB

Что такое автоматизация GitHub Actions

GitHub Actions - встроенная в GitHub система автоматизации. Её логика простая: когда произошло событие X, автоматически выполни действия Y.

GitHub Actions для новичка: Trigger → Workflow → Job → Step → Runner → PASS/FAIL

Trigger
событие, которое запускает процесс

Workflow
полный сценарий автоматизации

Job
крупный блок работы

Step
одно конкретное действие

Runner
компьютер, который выполняет команды

PASS
проверка успешна

FAIL
проверка упала

YAML
текстовый файл с инструкциями

Где это лежит

Файлы workflows обычно находятся в repository по пути .github/workflows/. Например: ci.yml или deploy.yml.

.github/
└── workflows/
    ├── ci.yml
    └── deploy.yml

Тебе не нужно уметь писать YAML с нуля. Но ты должен понимать, что этот файл задаёт: когда запускаться, что делать и какой результат считать успешным.

ДОСТУПЫ

Секреты и обычные настройки (Secrets / Variables)

Secret = скрытый ключ, Variable = обычная настройка, Environment = среда

Secret = секретное значение

Пароль, API key, SSH private key, database password. Такое значение нельзя коммитить в Git.

Где увидеть: Repository → Settings → Secrets and variables → Actions.

Variable = обычная несекретная настройка

Например APP_PORT=3000 или адрес публичного сервиса. Если кто-то увидит значение, это не должно создавать угрозу.

Пример	Куда	Почему
DATABASE_PASSWORD	Secret	Открывает доступ к базе
OPENAI_API_KEY	Secret	Деньги и доступ к API
APP_PORT=3000	Variable	Обычная настройка
PUBLIC_SITE_URL	Variable	Не секрет

Правило: название secret можно видеть. Реальное значение - нет. ИИ может попросить создать DEPLOY_SSH_KEY, но не должен выводить сам ключ в логах или README.

СРЕДЫ

Среды GitHub: тестовая и рабочая (staging / production)

Environment в GitHub - это цель deployment. Обычно новичку достаточно двух понятий:

Тестовая среда (staging)

Тестовая версия максимально похожая на настоящую. Здесь можно проверить выпуск до того, как его увидят реальные пользователи.

Рабочая версия (production)

Настоящая рабочая версия. Ошибка здесь затрагивает реальных пользователей и реальные деньги.

GitHub Environments могут хранить отдельные secrets и variables, ограничивать ветки и, в зависимости от тарифа и типа repository, использовать protection rules и approvals.

Почему это важно новичку:

Без разделения staging и production легко случайно подключить тест к настоящей базе или удалить реальные данные, думая, что работаешь в песочнице.

	Тестовая среда (staging)	Рабочая версия (production)
Кто пользуется	Ты и команда	Реальные пользователи
База	Тестовая	Настоящая
Secrets	Тестовые	Боевые
Можно экспериментировать	Да, осторожно	Нет

ГЛАВНАЯ КАРТА

Полный путь релиза от AI до пользователя

Главный путь выпуска: AI → ветка → Pull Request → автоматические проверки → тесты → тестовая среда → подтверждение → рабочая версия

AI создаёт изменение. Не в production напрямую, а в отдельной ветке.

Git фиксирует историю. Commit превращает изменение в конкретную версию.

Pull Request показывает разницу. Видно, какие файлы изменились.

CI автоматически проверяет. Ошибка должна останавливать движение дальше.

Merge добавляет проверенный код в main.

Тестовая среда (staging) показывает реальность. Версия запускается в среде, похожей на production.

Health, Smoke и E2E проверяют работу.

Подтверждение человеком даёт контроль над последствиями.

Публикация доставляет рабочую версию пользователям.

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

БАРЬЕР

Какие проверки должен запускать CI

Красный CI должен физически останавливать сломанный код до production

Lint

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

Type Check

Проверяет, что код не путает типы данных. Например, вместо числа случайно не передали текст.

Tests

Автоматические сценарии: дали входные данные → получили ожидаемый результат.

Build

Проверка, что из исходного кода действительно собирается версия, которую можно запускать в production.

Security checks

Базовые проверки утечек секретов, небезопасных dependencies и слишком широких permissions.

Минимальный CI новичка:

INSTALL → LINT → TEST → BUILD → PASS.

Не надо строить NASA. Нужен минимальный барьер, который реально ловит ошибки.

Статус автоматической проверки (Status Check)

Статус автоматической проверки (Status Check) - результат конкретной автоматической проверки. Если правило GitHub требует успешный check, красный результат может блокировать merge в защищённую ветку.

Защита основной ветки (Branch Protection / Rulesets)

Это правила, которые защищают важную ветку. Например: не разрешать обычный merge при красном CI, запретить force push или требовать Pull Request.

ДОСТАВКА

Как GitHub связан с VPS

Публикация - не одна команда. Это процесс доставки конкретной проверенной версии в среду, где она должна работать.

Слабая модель

SSH → git pull → restart → надеемся

Нормальная модель

проверенная версия
↓
production environment
↓
контролируемый deploy
↓
restart нужного service
↓
health
↓
smoke
↓
monitoring

Временный компьютер-исполнитель GitHub (runner)

Временный компьютер GitHub. Он появляется, выполняет workflow и исчезает. Хорошая базовая модель для CI.

Свой компьютер-исполнитель (self-hosted runner)

Runner на твоём собственном сервере. Это мощно, но опаснее: недоверенный код может выполняться прямо внутри твоей инфраструктуры. Для первого курса мы не делаем production VPS универсальной машиной для любых Pull Requests.

Контроль одновременных запусков (Concurrency)

Защита от двух production deploy одновременно. Если два релиза начинают менять один сервис параллельно, легко получить гонку и странное состояние.

Результат сборки и временный кэш

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

Запомни: Кэш ускоряет работу. Результат сборки является итогом процесса.

ПОСЛЕ ПУБЛИКАЦИИ

Проверка здоровья, быстрая и сквозная проверка: три уровня контроля

Health Check = «сервис вообще жив?»

Например endpoint /health возвращает healthy. Это ещё не означает, что все функции работают.

Smoke Test = «главное не отвалилось?»

Для бота: процесс запущен, Telegram доступен, база отвечает, критичный внешний API доступен.

E2E = End-to-End = сквозной тест

Проверяем путь реального пользователя от входа до результата. Например пользователь написал боту → бот сходил в AI → пользователь получил ответ.

CI/CD не заменяет тестирование из Гайда №13. Он запускает эти проверки автоматически в правильный момент.

ОПАСНЫЙ МОМЕНТ

Изменение базы данных (migration): почему код откатить легче, чем данные

Migration - изменение структуры или содержимого базы: добавить поле, создать таблицу, изменить формат данных.

Сценарий:

Новая версия удаляет колонку name. Потом новая версия приложения ломается. Ты возвращаешь старый код, но старый код ждёт name, которого уже нет. Код откатили, система всё равно сломана.

Безопасная логика

Сделать backup, если изменение затрагивает важные данные.

Проверить migration на staging.

По возможности сначала расширить схему, не удаляя старое.

Переключить приложение на новую схему.

Только после подтверждения удалить старое.

Любые destructive операции вроде DROP TABLE, DROP COLUMN, массовых DELETE и необратимых преобразований требуют отдельного human approval.

ПЛАН Б

Откат (rollback): сломалось - верни рабочую версию

Rollback: возврат с проблемной V18 на проверенную V17

Rollback - возврат к предыдущей рабочей версии. Смысл не в том, чтобы никогда не ошибаться. Смысл - быстро вернуть стабильность пользователям.

Known-good version

Версия, про которую доказано: она была deploy, прошла health и Smoke, пользователи реально могли работать.

Не путай rollback кода и rollback данных.

Вернуть application version часто легко. Вернуть удалённые или преобразованные production data может быть невозможно без backup и отдельного плана.

ТРИ УРОВНЯ ЗРЕЛОСТИ

Не строй Kubernetes ради пяти пользователей

Уровень	Что достаточно
1. Первый рабочий проект	Branch → PR → CI → manual deploy → Health → Smoke
2. Коммерческий продукт	Автоматические проверки → тестовая среда → сквозная проверка → подтверждение → рабочая версия → наблюдение → откат
3. Большая нагрузка	готовые сборки, контейнеры, поэтапный выпуск, автоматический откат и расширенное наблюдение

Сложность должна появляться только тогда, когда у неё есть реальная причина: деньги, пользователи, нагрузка или риск.

AI-FIRST ПРАКТИКА

12 готовых промптов

Не просто «сделай CI/CD». Каждый промпт заставляет ИИ сначала восстановить фактическое состояние, объяснить новичку смысл и потом доказать результат.

ПРОМПТ №1