Исходя же из скромного опыта, слияние множественных фич зачастую может ломать друг друга, что выявляется обычно на этапе тестирования. Совсем уж простые вещи отсекаются ещё на этапе слияния ветвей в системе контроля версий политиками, если не проходит сборка или автоматические тесты, остальное же требует внимания.
В идеальном мире, как мне видится, следовал бы немедленный rollback в случае возникновения ошибок на проде, что как раз скорее всего в ведении devops инженеров, а далее согласование конфигов с командой ответственной за них.
Вспоминая свой начальный опыт коммерческого программирования, попытка быстренько пофиксить релиз на горячую, обычно ведёт лишь к непредсказуемому поведению в других частях программы и переработкам в попытке все таки поднять релиз.
Всю жизнь сидел на Хабре, даже не регистрируясь, а после этой статьи захотелось написать комментарий.
Однако нюанс ситуации в том, что баг возник из-за кривого конфига Nginx
Интересно было бы узнать, кто в вашей разработке ответственен за конфигурацию nginx: devops, ваша команда разработки, другая команда.
Также методология scrum предполагает некоторого владельца продукта, которой в заданной области имеет право выбирать задачи и соответственно согласовывать изменения. Мне понятно желание пм везде и всюду пытаться приоритизировать свои фичи как самые главные, особенно обратившись напрямую к исполнителям, но если конфиги nginx например общие, я бы на месте devops тоже бы не стал по голосовому их править, потому что они также могут затронуть функционал других команд, а брать ответственность за потенциальные убытки бизнеса из-за голосового сообщения, которое нигде в системе разработки не логируется никто не захочет.
Эх первый же комментарий на Хабре и сразу минус.
Исходя же из скромного опыта, слияние множественных фич зачастую может ломать друг друга, что выявляется обычно на этапе тестирования. Совсем уж простые вещи отсекаются ещё на этапе слияния ветвей в системе контроля версий политиками, если не проходит сборка или автоматические тесты, остальное же требует внимания.
В идеальном мире, как мне видится, следовал бы немедленный rollback в случае возникновения ошибок на проде, что как раз скорее всего в ведении devops инженеров, а далее согласование конфигов с командой ответственной за них.
Вспоминая свой начальный опыт коммерческого программирования, попытка быстренько пофиксить релиз на горячую, обычно ведёт лишь к непредсказуемому поведению в других частях программы и переработкам в попытке все таки поднять релиз.
Всю жизнь сидел на Хабре, даже не регистрируясь, а после этой статьи захотелось написать комментарий.
Однако нюанс ситуации в том, что баг возник из-за кривого конфига NginxИнтересно было бы узнать, кто в вашей разработке ответственен за конфигурацию nginx: devops, ваша команда разработки, другая команда.
Также методология scrum предполагает некоторого владельца продукта, которой в заданной области имеет право выбирать задачи и соответственно согласовывать изменения. Мне понятно желание пм везде и всюду пытаться приоритизировать свои фичи как самые главные, особенно обратившись напрямую к исполнителям, но если конфиги nginx например общие, я бы на месте devops тоже бы не стал по голосовому их править, потому что они также могут затронуть функционал других команд, а брать ответственность за потенциальные убытки бизнеса из-за голосового сообщения, которое нигде в системе разработки не логируется никто не захочет.