Comments 9
А где вы отлаживаете пайплайн? Я имею в виду тот самый финальный .github.yml/ .travis/, .github/workflows и т.д.?
Чем больше я в индустрии, тем с большой тоской я смотрю на процесс написания и отладки именно этого. Потому что инструментов - только print, никаких 'mock-сред" для таких монстров не завезли.
Любая попытка принести стейджинг приводит к тому, что на стейджинге всё работает, а на продакшене свои переменные, которые "привносят вкус продакшена" и их всё равно отлаживают на продакшене.
С болью в отсутствии инструментария - согласен. Хоть и helm charts + argocd + crossplane очень помогают разгрузить пайплайн. Можно еще глянуть на стандарт Open Application Model. Но это все не про тесты пайплайна. Остаются ручные тесты на дев, или таки есть варианты получше?!
Вот про боль со вводом стейджинга - не понял. Если речь про пайплайны, то как и зачем им отличаться от прод окружений с технической точки зрения? С коротко-живущими еще понятно..
п.с. к авторам ни какого отношения не имею.
Остаются ручные тесты на дев, или таки есть варианты получше?!
Если говорить про результаты, то возможно testinfra, которая проверяет уже сам результат выкатки. Но это прям узкая часть.
Вот про боль со вводом стейджинга - не понял. Если речь про пайплайны, то как и зачем им отличаться от прод окружений с технической точки зрения? С коротко-живущими еще понятно..
Иногда с короткоживущими даже проще. Яркий пример из практики. Инфраструктура на проде у определённого проекта 60-80к облачных денег в месяц, а на тестовом сервере в подсобке - 0к/мес (ну фиг с ним, купим PC под нужды за 100к). Пример утрированный, но у условного облака один набор инструментов CD, а у стейджинга допустим этого нет (причин может быть больше, почему нет).
Если с короткоживущими можно поднять и опустить окружение потратив ресурсы за час, то стейджинг это условная "песочница", которая работает постоянно.
Речь о пайплайнах, а не том что выкатывается. Пайплайн должен абстрагироваться от деталей сервиса.
Коротко-живущие пайплайны отличаются от остальных енвов, как раз наличием доп. шагов по поднятию/тушению необходимой инфры и сервисов. Чего не должно быть для условного пре-прод.
Представленный пример с существенным отличием инфры дев/прод проблема не техническая, а финансовая. За что платят - то и получают. И еще не известно экономят ли..
Я спросил, где вы проверяете, что ваш финальный .yaml файл (в CI) рабочий. Интеграционное тестирование секретов, кода и данных.
Я в своей карьере столько нажрался ситуаций, когда стейджинг отполирован до блеска, но в продакшене секреты другие, и там всё при деплое начинает "как-то не так себя вести", что прям из профессии хочется уйти.
К сожалению, в Банке так же нет специальных инструментов по полноценной отладке pipelines.
Есть возможность отлаживать Kotlin-код pipelines, как цепочки вызовов, но исполнительная часть (ansible, python и т.д) не может быть проверена, пока не будет запущена.
Решаем вопрос унификацией используемых пайплайнов под разные стеки и последующим их тиражированием. Вначале все равно приходится проходить сложный путь откладки.
Такая унификация отчасти решает и проблему в различной конфигурации стейджинга с продом, но это отдельная проблема. Важно использовать единый инструментальный стандарт, единую архитектуру, единые образы виртуальных машин, базовые образы контейнеров и т.д.
Все так же как у всех, боль и страдания.
как вариант можно просто брать на работу нормальных разрабов, а не говно с курсов, ну и меньше обсуждать, а больше работать
Как запустить DevOps-конвейер на полную мощность