fbpx
Получится ли у вас Continuous Delivery?

выбор оптимального размера деплоя

На данный момент подход Continuous Delivery стремительно набирает популярность. Все больше начинают о нем говорить на конференциях, встречах сообществ, интервью и прочих выступлениях. Многие компании построили свой процесс разработки так, чтобы поставлять “свежие” фичи конечным пользователям десятки раз в день. В чем же тут дело? Почему для большей части компаний это еще является заоблачной мечтой и недостижимым идеалом?

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

Стоимость поставки уменьшается с количеством функциональности в этой поставке. Не надо, к примеру несколько раз в день производить тестирование, обновлять код на продакшене, делать обновления данных и т.д. Все это делается одним скопом в конце итерации или недели, месяца, квартала. Стоимость накапливания наоборот растет. Чем больше готовой функциональности ждет поставки, тем больше затраты на ее “содержание”. И тут вырисовывается вполне математически и экономически выверенное решение. Нужно минимизировать суммарную стоимость.

Графики стоимости в зависимости от размера релиза вы можете наблюдать на картинке. Стоимость накапливания очень тяжело уменьшить, так как она больше связана с бизнесом и конечными пользователями. Многие просто даже не считают эту стоимость и не задумываются о ней. Релиз раз в две недели? Ну и нормально! А то, что важная фича была реализована в первый же день и могла бы уже почти две недели использоваться, никого не волнует.

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

Подведем итог. Попробуйте расписать график стоимости поставки и накопления функциональности для своего проекта, а потом проверьте оптимально ли у вас выбрана частота релизов. Результатами поделитесь в комментариях к статье. Удачи!

Обсуждение (3)

Feature flags это во многом вопрос процесса. Это только кажется что они много стоят в разработке, точно так же как многим кажется что unit-test’ы писать дорого в разработке. Да, дорого, если в проекте такого изначально небыло (как и с unit-test’ами).
Мы сейчас внедряем по-маленьку и пока ощущение такое, что в проекте с нуля эта вещь из разряда “один раз сделал хорошо и потом сплошной гешефт”.

Ну и feature flags с мониторингом это не единственное что нужно. Нужна вообще хорошая devops инфраструктура с раскатом на бой и всем-всем-всем.

Мониторинг обязательно, без него вообще никуда. А feature flags – это в идеале. Просто они очень много стоят в разработке. 🙁

Еще обычно включают хороший мониторинг и средства быстрого отключения/отката какой-либо функциональности.

Leave a Reply

Your email address will not be published. Required fields are marked *

Pkv Games BandarQQ Online Terbaik Dengan Deposit Super Modern permainan paling populer di situs poker online terbaik di indonesia di situs bukaqq Poker Online Aman dan Terpercaya slot online