Готов выступить адвокатом trunk-based development flow.
Скептический пост в @oleg\_log
TBD - очень понятный для людей процесс, а это, как по мне, основное: technologies are easy - people are hard.
Благодаря простоте этого метода, метод встречается часто там, где это так никто и не называет. Например, в ops командах я часто видел trunk-based для работы с системами автоматизации (configuration mgmt, IaC, etc.)
Что касается разработки, для TBD действительно требует подготовки: окружения для тестирования отдельных фич, grey releases, подходящие стратегии выкатки и прочее. Но за это нам, собственно, и платят ¯\_(ツ)_/¯
Ну и дабы не быть голословым. State of DevOps by Puppet 2016 отмечают корреляцию между продуктивностью команд и TBD (сам отчёт). Корреляция - не причина, потому я не говорю, что TBD сам по себе приведёт вас к успеху, но практики, связанные с ним, однозначно полезны.
Готов дискутировать в чате CatOps
P.S. Но в манифесте TBD действительно сферический конь в вакууме описан 🙂
Скептический пост в @oleg\_log
TBD - очень понятный для людей процесс, а это, как по мне, основное: technologies are easy - people are hard.
Благодаря простоте этого метода, метод встречается часто там, где это так никто и не называет. Например, в ops командах я часто видел trunk-based для работы с системами автоматизации (configuration mgmt, IaC, etc.)
Что касается разработки, для TBD действительно требует подготовки: окружения для тестирования отдельных фич, grey releases, подходящие стратегии выкатки и прочее. Но за это нам, собственно, и платят ¯\_(ツ)_/¯
Ну и дабы не быть голословым. State of DevOps by Puppet 2016 отмечают корреляцию между продуктивностью команд и TBD (сам отчёт). Корреляция - не причина, потому я не говорю, что TBD сам по себе приведёт вас к успеху, но практики, связанные с ним, однозначно полезны.
Готов дискутировать в чате CatOps
P.S. Но в манифесте TBD действительно сферический конь в вакууме описан 🙂