Комментарии 5
что многие руководители не убеждены в преимуществах такого подхода. Надеюсь, что сегодня уменьшилось хотя бы относительное число таких руководителей
В статье конечно хорошо описаны преимущества и так далее. Но почему-то о недостатках все время упоминается в уничижительной форме.
Некоторые предметные области плохо поддерживают непрерывное развертывание (см. стр. 69 этого исследования), например, телекоммуникационное программное обеспечение и встраиваемое медицинское оборудование.
Да неужели нужно так далеко ходить за примером?
Как вы обеспечите непрерывное развертывание on-premises продукта или вообще домашних коробочных версий? А ведь это ОГРОМНОЕ количество софта.
Непрерывное развертывание это не панацея, а хороший инструмент для определенных продуктов. Но не все крутится в облаке и не весь продакшен вам доступен.
Да и множество архитектур могут быть просто не готовы к изменениям онлайн, а даунтайм возможен только в согласованное «зеленое время». И предлагать «поменяйте архитектуру» всегда должно идти «а точно ли это выйдет в конечном счете дешевле, выгоднее и удобнее».
Я полностью поддерживаю CD, и есть множество прекрасных способов это сделать, начиная от скриптов и популярных оркестраторов, и заканчивая специализированными uDeploy, Octopus и др. Но преимущества и недостатки следует указывать не вообще, а на примерах конкретных приложений (архитектур).
о недостатках все время упоминается в уничижительной форме
Прошу уточнить, потому что именно этот раздел я старался сделать более конструктивным и менее «задиристым».
Как вы обеспечите непрерывное развертывание on-premises продукта или вообще домашних коробочных версий?
Да, тут немного сказалась моя профессиональная деформация. Пожалуй, чтобы указать «преимущества и недостатки… на примерах конкретных приложений», надо будет подготовить ещё аналогичный по объёму материал. Поэтому я просто укажу это соображение в разделе «Затраты» или «Препятствия».
Прошу уточнить, потому что именно этот раздел я старался сделать более конструктивным и менее «задиристым».
Увы, оказалось, что есть и совершенно другие люди (вы можете узнать их по таким странными выражениям, как «качество продукта», «ресурсы», «скорость исправления ошибок», «трудозатраты»), которым нормальные ценности чужды.
Вот этот абзац прям странный. Любой разработчик должен понимать сколько стоит вывести в продакшен, сколько стоит исправить ошибку, как сделать качественный продукт. Может быть не каждый считает это в конкретный цифрах в валюте, но должен понимать, что в разных проектах это может быть от почти бесплатно до заводской штамповки за миллион =)
Вдобавок, у меня сложилось впечатление, что вы путаете автоматизацию деплоймента в прод и Continuous Delivery.
Жители Villabajo выкатывают изменения раз в две недели. В отличие от серьезных b2b-контор из столицы 6-й экономики мира, у жителей Villabajo действительно четко запланирован объем каждого спринта, а еще они научились проверять, все ли нужное вошло в версию (и не попал ли туда мусор), в полуавтоматическом режиме.
Тем не менее каждый житель Villabajo регулярно тратит по несколько часов, чтобы:
И вот тут может быть не так.
Подготовленный релиз один раз проверен, протестирован, протегирован, запланирован. Все, никаких «регулярных» трат нет — все дополнительные изменения просто переносятся в следующий релиз.
А это подготовленный в релиз, в запланированное время задеплоится по нажатию кнопки, без лишних телодвижений. Может быть даже и нажимать не нужно, запланировать нажатие тоже можно заранее.
В крайнем случае, конечно, может выйти срочный хотфикс, мало ли что, но это при багах критического уровня.
В общем при сравнении более-менее удачно настроенного CD и плохо настроенного не-CD, естественно CD выглядит хорошо, но от такого сравнения ощущения развода =)
Вот этот абзац прям странный...
О-о, я думал, замечание об «уничижительной форме» относится к тому, что написано в разделе «Затраты» ближе к концу заметки. А приведённый вами абзац из введения специально написан в провокационном стиле; и, вижу, провокация удалась ;-)
И вот тут может быть не так… Все, никаких «регулярных» трат нет — все дополнительные изменения просто переносятся в следующий релиз...
Если в описании процесса появляется слово «просто», то вот наверняка всё будет совсем непросто. И в ваш комментарий, на мой взгляд, это слово-маркер удачно поместилось, ведь критикуя мою идеализацию CI/CD, вы в ответ сами привели идеализированный не-CI/CD. Так что я с вами согласен, но не согласен: на практике и CI/CD, и не-CI/CD будут отличаться от теоретического описания множеством деталей (да, получилось немного как у КО).
CI отдельно, CD отдельно
Задача CI — работа с фича-бренчами и в конечном счете автоматизированное создание деплой пакета для CD
А будет ли CI триггерить CD или только подготовит, после чего CD будет ждать «формального» аппрува и нажатия на кнопку — это уже и есть разница между автоматическим деплоем на продакшен или отдельном, заранее запланированном процессе, но тоже автоматическом.
Последние несколько лет (даже не один проект), все именно так — полная автоматизация, но вывод в продакшен триггерится не очередным коммитом, а аппрувится менеджментом.
Задача CI — работа с фича-бренчами и в конечном счете автоматизированное создание деплой пакета для CD
А будет ли CI триггерить CD или только подготовит, после чего CD будет ждать «формального» аппрува и нажатия на кнопку — это уже и есть разница между автоматическим деплоем на продакшен или отдельном, заранее запланированном процессе, но тоже автоматическом.
Последние несколько лет (даже не один проект), все именно так — полная автоматизация, но вывод в продакшен триггерится не очередным коммитом, а аппрувится менеджментом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем нужны непрерывная доставка и непрерывное развертывание?