Контекст

Команда разработки, которая хочет перейти на Trunk-Based Development, должна быть морально, технически и инфраструктурно готова к этому. После того, как команда сделает хотя бы несколько коммитов в соответствии с правилами, становится гораздо проще интегрировать в команду другие классные штуки. Мы с вами можем это увидеть на диаграмме:

DevOps тоже входит в эту практику. По крайней мере, начинается распространение лучших практик разработки в операционных центрах.

Предпосылки для Trunk-Based Development

(слои под Trunk-Based Development)

Надежная инфраструктура для разработки

Установка вашей системы контроля версии это часть фундаментальной инфраструктуры разработки, которая включает в себя рабочие станции или ноутбуки разработчика, подходящие для сборки, тестирвоания и запуска создаваемого приложения или сервиса. Разработчикам, которые запускают приложение, нужно чтобы оно работало с точки зрения функционала. Оно не обязательно должно соответствовать показателям производительности в ожидаемой боевой среде, и это нормально если приложение отличается нефункционально и в других отношениях.

В современную эру DevOps, это, возможно, означает Инфраструктура как Код.

Вещи, которые облегчают Trunk-Based Development

(слои над Trunk-Based Development)

Continuous Integration

Continuous Integration (CI) использовалась с серединых двеяностых в ее современном воплощении (частые вливания кода в общую ветку и тестирование этих изменений).

Важно заметить, что существует большое совпадение между Trunk-Based Development и Continuous Integration, которое было определено их создателями и составителями документации. В то время, как Trunk-Based Development фокусируется на чистом подходе к работе в системе контроля версий и накладывает определенные обязательства на человека, который с этим работает, Continuous Integration фокусируется ровно на том же, а также на необходимости автоматических предупреждений при поломках и несовместимостях.

Continuous Delivery

Continuous Delivery (CD) это слой на вершине диаграммы, практика была придумана и используется с середины 2000-х. Она была описана в книге с одноименным названием авторами Джезом Хамблом (Jez Humble) и Дейвом Фарли (Dave Farley) и вышла в 2010 году. Этот сайт дает 5% информации об этой практике. Читателю следует как можно скорей ознакомиться с этой книгой и связанным с этой практикой сайтом.

Бережливые эксперименты

Если у вас нет CD, то можно проводить эксперименты по непрерывному улучшению с акцентом на время через “машину”, которая помогает при разработке и выкладке. Эксперименты должны выходить за рамки той области науки, которая называется «бережливым подходом», чтобы можно было измерить влияние каждого эксперимента на основании прогнозов и решений, принимаемых в соответствии с ним.

Бережливые эксперименты могут быть в любой команде и в любом проекте, но работают лучше всего там, где надежная основа. В частности, надежная основа из Trunk-Based Development, CI, и CD.

Этот сайт не касается экспериментов по бережливому производству за пределами этого раздела, но читатель должен стремиться понять эту область науки, когда нижние слои диаграммы являются надежными.