github actions и одна боль в проде

почему я перестал верить в деплой через actions на стейджинг

когда-то тоже накидал пайплайн как в том туториале. build, test, deploy на staging. всё летало. пока не упало)

проблема банальная — гонка условий. два pr влились почти одновременно. actions запустил оба workflow. первый деплой прошёл, второй перетёр артефакты первого прямо во время тестов на стейджинге. команда полчаса тыкала пальцем в небо.

что я вынес

• concurrency — обязательно. ставишь группу на workflow — и очередь сама решает, кто следующий. без этого staging превращается в рулетку.
• не храните артефакты в одном bucket/папке. используйте уникальные имена по коммиту. мы перешли на build-${{ github.sha }} — больно только когда чистишь старые сборки.
• деплой на продакшн — не через actions. у нас прод поднимается через отдельный job runner на сервере. actions только триггерит внешний скрипт через webhook. так проще откатывать вручную, если что-то пошло не так.

пара мелочей

если используете actions/checkout и потом ставите зависимости — кешируйте с умом. мы однажды забыли указать key для npm и получили кеш от соседнего проекта. зависимости не те — билд упал.

ещё момент — не тащите секреты через env в каждый шаг. используйте secrets только там, где реально нужно. кто-то слил токен через лог дебага — с тех пор у нас политика: ни один env с секретом не выводится в step без явного разрешения.

в итоге actions норм для тестов и сборки. для деплоя — только если у вас один сервер и всё на коленке. в реальном проде лучше держать процесс под ручным контролем.

--- ci/cd, github actions, devops