Подскажите пожалуйста по поводу continuous delivery/deployment. Сколько не пытался найти,

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

У меня свое веб приложение. Вот есть у меня ветка main. Методология у меня GitHub flow (одна ветка и в нее все херачат всё через PR). У меня есть только прод env, насчет тест env см. ниже.

Есть GitHub Actions workflow с двумя job:
- build (билдит приложение и создает артифакт, загружает его на GitHub)
- test (скачивает артифакт, запускает миграции, добавляет тестовые данные в БД, запускает тесты в подобии тест env)

Этот workflow срабатывает на любой пуш в любую ветку, как я и хочу.

Теперь я хочу автоматически деплоить в прод при push в мастер, но, внимание,
Я ХОЧУ РЕЮЗАТЬ артифакт со стадии билда, а не билдить заново. Как мне его тегать? Вы скажете, commit hash? Так он меняется в зависимости от типа merge.

ЧТО ДЕЛАТЬ, ПОДСКАЖИТЕ, 5 лет опыта блять

FluxCD

Я не использую докер 🥹

использовать git tags? Успешные тесты - затегал коммит - затегал артифакт. Деплоишь последний затеганый артифакт (по соответствию git тега). Ну или переменной указывать конкретный

Идея мне нравится Но получается нужно не просто нажать кнопочку merge, а еще создать в нужное время tag и запушить его Проблема вроде появляется, что можно нажать кнопочку и забыть запушить тэг

теги нужно создавать, когда успешно прошли тесты - тоесть это в джобу с тестом

То есть можно иметь файл типа app_version на основе которого называется тег? Так как commit hash не вариант, я так понимаю

да, просто вести соответствие, git tag - как ссылка на нужный коммит - то есть нужную версию которая прошла тесты. И git tag - будет как список версий = список артефактов. А какой деплоить выбираешь сам : - последний (выбирается легко) - конкретный (но тогда нужно пайплайн запускать руками, чтобы указывать нужную версию) - ввиду того что прод - это не выглядит как зло)

Очень привлекательно, но значит ли это, что все, кто не используют теги, не имеют правильно и полностью автоматизированный CD То есть идея в том, что git теги почти никто не использует на коммерческих проектах, из того, что я видел

эм.. я не скажу за коммерческие, но хранить версию в ветках, или в тегах - это очень популярно. Это прям бестпрактикс. А насчет правильно и полостью автоматизированный СD - тут нельзя обобщать, потому что у всех разные задачи, разные условия, и разный flow. По git flow например куча веток, это отличается от вашего подхода. Кто то собирает docker образы, и кладет их в регистри, а за ним следит какой нибудь argocd и сам накатывает новые версии. Кто то прям джобой в пайплайне катит по стендам, и на каждом проводит тесты автоматизировано. Тут вариаций множество =)

Git flow раньше использовал, но это нереально по двум причинам: 1. Девелоперы его не любят, он слишком для них сложный 2. Сейчас я так понял считается, что релиз ветки это антипаттерн 3. Вроде ещё сложнее автоматизировать чем то, что я сейчас пытаюсь сделать

Спасибо 🙏

я вот честно говоря вот эту статейку и подобную ей читал когда искал флоу https://www.bmc.com/blogs/devops-branching-strategies/

❤️

А в чем сакральная проблема: А) пересобрать арт из мастера/релизбранча Б) переименовать/мувнуть уже собранный после мержа

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

1. Нет гарантии, что получится тот же артифакт, засчет внешних факторов (зависимости и тд), даже при использовании composer.lock 2. Из-за п.1, нет гарантии, что это артифакт будет работать так же, как тот, который был создан ранее.

1) Ну как бы локфайлы как раз про гарантию. 2) вут? Я и говорю, просто промоутни

Между окончанием тестов и деплоем может быть разница во времени, соотв. используется новый запуск того же (или другого!) GitHub workflow. 1. Если брать actions/download-artifact, то ему доступны только артифакты из того же запуска. Окей, можно использовать другое хранилище артифактов (напр S3) или не использовать официальный actions/download-artifact 2. Так как это отдельный запуск, и делает он другие вещи, то он должен чем-то триггериться, то есть отдельным типом события, а не тем, каким был создан артифакт. 3. Артифакт нужно скачивать по какому-то имени/тегу. Окей, имя всегда одинаковое. Остается тег или динамическая часть. Если мы делаем ее равной commit hash, то мы ошибаемся, так как финальный HEAD commit hash в ветке main, в которую мы мерджим PR, может и будет отличаться в зависимости от типа merge (fast forward, squash или иной). Таким образом, по commit hash уже нельзя получить изначальный артифакт

Билдить надо только один раз, я на этой идее зациклен 🤪

После коммита в мастер у тебя должны заново прогоняться сборка и тесты.

Антипаттерн! Так это конечно легко

Ну тогда промоути

Это не антипаттерн, это обычно так и делается.