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

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

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

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

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

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

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

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

Обсуждение (
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
3)

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

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

принять
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