Комментарии 5
Подробнее про cft-approver в моей статье
С точки зрения бизнеса выполнялись все требования при выкатке приложения, оно в бою, деньги зарабатываются
Тык если вы требуете с разработчиков приложений только красивой выкатки, то выкатка будет красивой. Больше красивым не будет ничего, включая эксплуатацию после выкатки, потому что это не требуется. Вот засунули автомат, который чего-то там проверяет про резервные копии и мониторинги и без этого не пускает выкатку дальше - они сразу появились, мониторинги эти. Магия, не иначе.
Вы же работаете с наёмниками, цель которых - заработать как можно больше денег как можно меньшими усилиями. «Самодостаточный» разработчик у вас это тот, кто может делать всё, но это совершенно не означает, что он будет делать всё.
Полностью поддерживаю. Вы абсолютно правы. Как иллюстрация. Требуем с разработчиков выполнения дисциплина «мониторинг», то, утрировано, получим наличие эндпойнты мониторинга. Только вот данные будут там мусорные.
Получается, что какими политиками ты не обложишься - все равно они будут проверять только выполнение самих себя, что к реальности может отношения чуть менее, чем никакого.
Что же делать в такой ситуации? Во-первых, очевидно, что нужны сотрудники, которые будут не временщиками. Потому что если менеджер уйдёт завтра, то он будет «эффективно» работать на достижение краткосрочных целей, а они далеко не эквивалентны долгосрочным. Разработчик так же - будет делать тяп-ляп, потому что не ему поддерживать его код. Во-вторых, нужны реальные метрики и реальные способы поощрить их выполнение. Например, не столько важно наличие мониторинга, как выполнение базового стандарта, а как минимизация времени отскока при авариях (и вот это уже можно прописать в цели). А уж какими способами разрабы будут этого добиваться - мониторингом, логированием или, ну, не знаю, гномики там будут чинить софт - это уже проблема именно команды разработки.
какое-то двойственное чувство после прочтения статьи. С одной стороны много крутого движняка, а с другой стороны то процесс выкатки изменений в продуктив ровно такой-же, как был в 90х, когда программеры сами выкатывали изменения на прод под личную ответсвенность (правда тогда не было этих всех модных понятий devops, kubernetes и что-то там еще из молодежного). Потом появилсиь стандарты безопасности, которые стали регулировтаь процессы выкатки изменений. И вот то, что у вас получилось ну никак не совпадает с рекомнедациями в стандартах. уроборос в общем получился.
Было бы очень неплохо добавить в начало статьи список терминов/сокращений и их расшифровки, как-то:
DEV
OPS (Ops)
DevOps
NoOps
TTM (Time to Market?)
Потому что, если спросить десяток человек, чем отличается OPS от DEV и что такое NoOPS на практике - получите 2-4 различных расшифровок/концепций.
500 Dev на 10 Ops, или Как внедрить NoOps в масштабе