использовать дефолтные хклсчеки Куба достаточно? Хотелось бы, чтобы билд и депло1 прошёл, потом чекнулись урлы, что приходит code 200 и только тогда завершить деплой, а если не 200, то обрушить пауйплайн
Да, используйте кубовые пробы, мы отслеживаем их состояние. Если не могут отработать при деплое деплойментов и других контроллеров, то мы упадём
А подскажите вообще по структуре. Например обновление pip пакета рушит апи. При этом этап сборки корректен, и сам деплой проходит (запуск джанги проходит без ошибок), но сами ручки при этом ломаются. Такой кейс это как раз хелсчеками отлавливать, или это все же ближе к тестированию и это задача тестировщика?
Какие ручки ломаются? Не понял
Рест апи основное с бизнес логикой.
То бишь билд без ошибок, деплой тоже, но по факту образ не работоспособен
т. е. вы задеплоили один сервис в релизе, а падает после этого другой сервис в другом релизе?
Сервис один. Как раз. И вопрос про то, как лучше отлавливать такие кейсы, когда какой-нибудь пакет или ещё что, ломает бизнес логику, но при этом билд и деплой без ошибок проходят. Я верно понимаю, что это по идее надо проверять уже после деплоя с помощью автотестов? То бишь билд прошёл, деплой тоже деплой проверяется хелсчеком, что сам контейнер запустился и command в контейнере не выбил ошибку, а вот саму работоспособность бизнес логики уже после деплоя отдельным запуском тестов прогонять?
а чек джанги проходит?
Проверять лучше до деплоя
Ага, то бишь ломается именно бизнес логика
Получается, перед деплоем сделать джобу test и в ней выполнять werf compose с поднятием инфраструктуры и запуском тестов?
Если я правильно понял, то выставьте startupProbe, которая проверит то, что джанга реально поднялась и может получать трафик. Статус проб верф отслеживает ещё при деплое
мы кстати у себя так и сделали, эт точно работает)
Это именно корректность запуска проверяет? А готовность принять трафик получается надо проверять корректностью выполненных тестов, которые бизнес логику проверяют ещё перед деплоем?
всё что можно протестировать перед деплоем, лучше протестировать перед. + сделать старт тест
Обсуждают сегодня