Чек-лист перед публикацией

один раз на проект и один раз на выпуск

Что это

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

Один раз на проект

1. Идентификатор приложения. Не com.example. После публикации не меняется (статья 12.2).

2. Ключ подписи и его резервная копия. В двух местах, ни одно из них — твой рабочий компьютер.

3. Файл .gitignore — проверен руками, а не взят на веру. Вот настоящий .gitignore из свежего шаблона популярного сборщика:

node_modules
dist
dist-ssr
*.local

Строки для .env в нём нет. Проверка: создаём файл .env с ключом и делаем обычный git add -A:

$ git ls-files | grep -c "\.env"
1

Секрет уехал в репозиторий. Не потому, что кто-то ошибся, а потому, что шаблон так устроен: *.local закрывает .env.local, но не .env. Отсюда правило: после первого коммита посмотри своими глазами, что именно попало в репозиторий:

git ls-files

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

4. Файл с точными версиями закоммичен — package-lock.json, pubspec.lock, poetry.lock (статья 12.1).

5. Сборка проверена из чистого клона. Не из своей папки, где всё уже работает, а так:

git clone <твой репозиторий> /tmp/proba
cd /tmp/proba && npm ci && npm run build

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

6. Версия видна в самом приложении. Строка на экране «о программе» или в подвале сайта. Без неё разговор с пользователем о поломке невозможен.

7. Настройки кэширования хостинга. Файлы с хэшем — надолго, index.html — никогда (статья 12.3).

8. Логи и ошибки где-то собираются. Иначе о поломках ты узнаёшь от пользователей.

Перед каждым выпуском

1. Проверки не отключены. В команде сборки на месте то, что её проверяет: tsc -b, mypy, flutter analyze. Отключали ли их с прошлого раза — смотреть в истории изменений, а не вспоминать.

2. Тесты прогнаны. Хотя бы те, что есть (глава 4).

3. Сборка с нуля. Удалить dist, build, папку зависимостей и собрать заново. Старые артефакты умеют скрывать поломки.

4. Поиск секретов в артефакте. Буквально:

grep -r "sk-\|secret\|password\|api_key" dist/

Нашлось — это утечка, а не придирка (статья 12.1).

5. Ресурсы на месте. Картинки, шрифты, файлы данных объявлены в настройках сборки и присутствуют в артефакте.

6. Версия поднята. Для магазина — число обязано вырасти.

7. Запущен артефакт, а не исходники. Открыть собранную папку, установить собранный пакет, поставить собранный .apk на телефон. Проверка исходников проверяет не то, что получит пользователь.

8. Изменения в API и базе разобраны по статье 12.3. Что добавлено, что переименовано, что не откатывается.

9. Записано, как откатиться. Одна строка: команда или номер предыдущего выпуска. Писать её надо до публикации, потому что после — будет некогда.

Как сказать ИИ

Составь чек-лист публикации под мой проект.
Стек: <перечисли>. Публикуется: <куда>.
Раздели на «один раз на проект» и «перед каждым выпуском».
Только то, что относится к моему стеку, без общих советов.
Оформи списком, который я положу в репозиторий.

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

Вот мой .gitignore: <содержимое>.
Что из обычного для этого стека в нём не закрыто?
Отдельно: что из уже закоммиченного похоже на секрет.

Я собрал проект. Напиши команды, которыми проверить
артефакт перед публикацией: поиск секретов, наличие
ресурсов, запуск собранной версии. Под мою ОС: <какая>.

На что смотреть

Чек-лист в голове. Пока он не написан, он разный каждый раз.

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

Правка прямо в артефакте. Поправили файл в dist/ или на сервере, чтобы быстро починить. Следующая сборка это затрёт, и поломка вернётся — уже без объяснения причин.

Публикация без возможности откатиться. Ты не знаешь, как вернуть прошлую версию, пока не попробовал.

Шпаргалка