Почему релиз кода — это задача БИЗНЕСА, а не только IT? Всё о Continuous Delivery

Интуитивно кажется, что большие изменения эффективнее маленьких.

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

Эта логика работает во многих сферах жизни, но плохо работает в сложных системах.

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

Поэтому риск определяется не количеством релизов.

Риск определяется количеством изменений, которые были объединены в один релиз.

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

Чем дольше организация откладывает изменения, тем больше взаимосвязей успевает накопиться между ними.

В результате самым опасным событием становится не сам выпуск новой версии, а ожидание перед её выпуском.

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

Подробнее в разборе идеи из книги Джеза Хамбла и Дэвида Фарли «Непрерывная поставка»: https://www.youtube.com/watch?v=nKItIuZN7DE