К счастью, за свою карьеру я встречал очень мало инженеров, которые категорически возражали против непрерывного развертывания.
Пост Непрерывное развертывание! = Постоянные сбои впервые появился на Qvault.
К счастью, за свою карьеру я встречал очень мало инженеров, которые категорически возражали против непрерывного развертывания. Тем не менее, я встречал некоторых, и я думаю, что их нерешительность обычно коренится в мифе о том, что непрерывный цикл вызывает больше сбоев у конечных пользователей, чем цикл пакетного выпуска.
Что такое непрерывное развертывание?
Прежде чем мы углубимся в подробности того, почему непрерывное развертывание (CD) почти всегда лучше, чем пакетные выпуски, давайте определимся с некоторыми терминами. Atlassian определение CD близко, но я собираюсь немного изменить его для своих целей. В отличие от них, я не думаю, что CD требует непрерывного интеграционного тестирования, но почему вы не стали бы запускать тесты, я не понимаю.
Непрерывное развертывание (CD) - это процесс выпуска программного обеспечения, при котором новые версии развертываются в производственной среде при соблюдении определенных условий в репозитории кода.
– Me
Например, я много работаю в Kubernetes, поэтому мой компакт-диск часто состоит из сценария действий Github, который запускается, когда я добавляю код в ветку main. Сценарий запускает Helm chart, который обновляет развертывания в кластере.
Есть много способов настроить хороший конвейер компакт-дисков, но общим является то, что при срабатывании триггера (слияние кода или создание тега) новое развертывание отправляется в производственную среду автоматически. Это делает развертывание кода максимально безболезненным для разработчика. При идеальном непрерывном развертывании доставка обновлений - это не что иное, как просто написание обновлений.
Разве непрерывное развертывание не вызывает больше ошибок?
No.
Я настоятельно рекомендую книгу Accelerate, в которой используются практические примеры, чтобы продемонстрировать положительное влияние современных практик DevOps. В книге они сравнивают высокоэффективные организации, занимающиеся разработкой программного обеспечения, с низкоэффективными организациями. По их данным, высокопроизводительные компании:
- Развертывайте код в ~ 46 раз чаще в продакшн
- Ускорьте время развертывания фиксации в 440 раз
- Иметь в 5 раз меньшую частоту отказов при изменении («отказы» - это «результат [ы] ухудшения качества обслуживания или последующего исправления (например, приводит к ухудшению качества обслуживания или отключению, требует исправления, отката, исправления вперед или исправления). )
- Среднее время восстановления после сбоев в 170 раз быстрее
Хотя данные говорят сами за себя, они также имеют смысл с качественной точки зрения. Наличие систем, которые автоматизируют доставку кода, чтобы отнимать меньше времени, по своей сути не создаст больше ошибок. Это процесс перед компакт-диском, который отвечает за обнаружение ошибок. У нас может быть отдельное обсуждение непрерывной интеграции и того, как это уменьшает количество ошибок, попадающих в рабочую среду, но процесс автоматизации развертывания ортогонален в этом отношении.
Непрерывное развертывание не создает дополнительных ошибок, но упрощает исправление существующих ошибок.
Разве непрерывные обновления не мешают конечным пользователям даже без ошибок?
Они могут быть, но это зависит от обстоятельств.
Пример - DotA 2
Я фанат популярной компьютерной игры DotA 2. Как пользователь их игры, меня очень раздражает то, как часто они выпускают небольшие обновления патчей. Для меня не редкость играть в три или четыре игры подряд, и мне приходится загружать обновления между играми. Это очень разрушительный опыт, потому что для обновления я должен закрыть игровой клиент, загрузить патч и перезапустить игру.
Проблема с тем, что делает DotA 2, не в том, что они (могут) делать компакт-диски, а в том, что они не сделали процесс исправления бесшовным. Например, они могут разрешить загрузку патчей, пока игра открыта, как это делает Blizzard со своей программой запуска. Кроме того, они могут пометить определенные виды обновлений как «ленивые», например, для исправления несущественных ошибок не потребуется перезапуск игры, они просто обновятся при следующем закрытии игры.
Пример - обновления пользовательского интерфейса
Другая распространенная жалоба заключается в том, что при непрерывном развертывании пользователи будут постоянно разочарованы тем, что функции и макет приложения меняются из-под них.
Это проблема не с компакт-дисками, это проблема с планированием продукта.
Тот факт, что непрерывное развертывание дает нам инструменты для развертывания изменений UI / UX с меньшим трением, не означает, что мы должны делать это все время. Конечно, вероятно, нет ничего страшного в том, чтобы изменить формулировку всплывающих подсказок или сделать оттенок красного немного темнее, но слишком частое развертывание дикого меню и изменений макета - ужасная идея.
Определите скорость изменений, с которыми согласны ваши клиенты, и построите свою дорожную карту на основе этого. Опять же, это не имеет ничего общего с вашими процессами развертывания.
У непрерывного развертывания есть только положительные стороны в контексте UI / UX. Когда вы обнаруживаете опечатку в каком-либо пояснительном тексте, вы можете исправить это в течение нескольких минут, никто не хочет вручную создавать, ssh, извлекать, останавливать и запускать сервер для чего-то столь тривиального.
Пример - Backend Web
Когда я обновляю код на внутреннем сервере, я могу развернуть этот проект асинхронно, не влияя на конечного пользователя. Нет причин не использовать непрерывное развертывание в таких средах, если изменения обратно совместимы.
Обратная совместимость имеет решающее значение в процессе непрерывного развертывания, когда несколько проектов имеют асинхронные циклы выпуска. Бессмысленно указывать на то, как несовместимые с предыдущими версиями изменения в REST API нарушат работу существующих клиентов. Те же проблемы могут возникнуть без непрерывного развертывания.
Спасибо, что прочитали, теперь пройдите курс!
Заинтересованы в высокооплачиваемой работе в сфере высоких технологий? Посещайте собеседования и успешно проходите их после прохождения практических курсов программирования.
Вопросы?
Подпишитесь на меня в Twitter @q_vault, если у вас есть какие-либо вопросы или комментарии. Если я допустил ошибку в статье, обязательно дайте мне знать, чтобы я исправил ее!
Подпишитесь на мою рассылку, чтобы получать больше статей по кодированию прямо на ваш почтовый ящик.
