Выбрать правильный день для развертывания программного обеспечения не так просто, как можно подумать. Существует много факторов, влияющих на это решение, как внутреннее, так и внешнее. В этой статье представлены мнения практикующих DevOps о том, что они считают оптимальным днем для развертывания программного обеспечения.
Люк Филипс, владелец Patrick Consulting и бывшего инженера -программного обеспечения в крупной издательской компании, шутит, что классическая практика в организации, в которой он работал, была развернута в пятницу, и все выходные, чтобы исправить отключение.
Но помимо шуток, желание защитить клиентов от икот развертывания имеет решающее значение для выбора подходящего времени для развертывания программного обеспечения для производства.
Учитывая влияние на конечных пользователей
Мэтт Акри, инженер полевых услуг в организации здравоохранения, сказал, что развертывание в пятницу часто обусловлено необходимостью минимизации потенциального негативного влияния на пользователя. Если вы думаете, что влияние будет минимальным и хотела бы отчетность по вопросам пользователей в реальном времени, предпочтительнее развертывание в середине недели; Однако, если ожидание состоит в том, что может быть серьезное время простоя, то в пятницу в нерабочее время, когда ваши команды по вызову наготове были бы маршрутом, чтобы идти, он советует.
Производство против развертывания не продакшн
Развертывание в середине недели также является предпочтительным временем для Рахула Кумара Вермы, инженера DevOps в Infosys. Он рекомендует планировать развертывание производства в середине недели, а не в пятницу, как говорит: «Зачем попасть в беду, если производственное приложение снижается?» Поскольку пятница-непроизводственные дни, вы можете завершить свои обновления и подготовить вещи к понедельнику на следующей неделе.
Тем не менее, для развертываний не продакшн он говорит, что вы должны развернуть по мере необходимости, включая пятницу. Это мнение также разделяется Найлом Хаттоном, основателем Pilotplan. Как он говорит: «Не развертывайте производство по пятницам. Но все остальное — справедливая игра в любой день, в любую неделю».
Важность твердого плана отката
Mandeep Sharma, директор DevOps в крупной компании здравоохранения, развевает миф о том, как избежать развертывания в пятницу. По его мнению, это костыль, чтобы быть более безопасным, если что -то пойдет не так, когда команды нет рядом. Он является сторонником твердого процесса развертывания, который может обнаружить сбои с помощью автоматизации/SRE. Отсутствующий шаг, который он часто видит, — это твердый план отката, который делает развертывание более безопасными.
Почему быстрые циклы обратной связи имеют решающее значение
По мнению Orion Edwards, ведущего инженера -программиста в Octopus Deploy, выбор дня для развертывания зависит от того, насколько быстро находится ваш цикл обратной связи. Например, если ваша система занимает 12-24 часов для развертывания в разных регионах, развертывание в пятницу днем может означать, что она не достигает всех регионов до поздней субботы. Это может привести к плохим выходным, если возникнут какие -либо проблемы.
Даже если ваше развертывание эффективно мгновенное, если у вас есть глобальная клиентская база, развертывание в пятницу днем может не затронуть критического клиента до субботы из -за часовых поясов. Но если у вас быстрые отзывы и понимаете такие вещи, как потенциальное местное/глобальное влияние, вы можете развернуть любое время, которое вам нравится.
Как продвигает успех автоматизации развертывания
Пол Дэвис, инженерный менеджер в Европейском банке, соглашается с тем, что выбор правильного дня развертывания все еще делит сообщество. С его точки зрения, речь идет о том, чтобы иметь уверенность в том, чтобы выпустить производство, и есть ряд инструментов и стратегий для его поддержки. Они могут варьироваться от ручных тестировщиков QA и промежуточных сред до широкого спектра автоматизированных тестов, развертываний канарейки и передового автоматического мониторинга.
Кроме того, есть немедленная обратная связь от пользователей производства, которые заметят, если что -то сломается. Эта обратная связь возвращается к инженерным командам, которые затем могут отменить изменение или применить исправление.
В идеале, в идеале, мы должны быть в состоянии развернуться в 17:00 в пятницу, уверенно, что наши автоматизированные тесты и мониторинг поймают любые проблемы. Плохое развертывание может быть автоматически отозвано в производстве, а билет с ошибкой, поднятый для адресации в следующий рабочий день. В действительности, однако, из того, что он видел, этот уровень автоматизации (и доверия) чрезвычайно трудно достичь. Так что, если вы предпочитаете выходные без стресса, это, вероятно, лучше не развернуться к производству, как последнее, что вы делаете в пятницу днем.
Факторинг в благополучии команды
По словам Катерины Бахмат, инженера DevOps в UITWARE, избегание развертываний по пятницам является наилучшей практикой, когда речь заходит о благополучии команды. К концу недели инженеры и другие обычно устают, что может привести к ситуациям, когда ошибки чаще случаются. Кроме того, если развертывание содержит ошибки (которые случаются время от времени), оно может привести к увеличению рабочих нагрузок и расширенного рабочего времени — и в некоторых случаях это может даже потребовать работы в течение выходных.
Она также отмечает, что каждая ситуация отличается, и иногда необходимо развертывание в пятницу; Тем не менее, по ее опыту, лучше завершить другие задачи в пятницу и развернуть со свежим умом в понедельник.
Как важна организационная зрелость и ресурсы
Барбара Теругги, архитектор безопасности в глобальном поставщике ИТ -услуг, перечисляет уровень зрелости в качестве ключевого элемента для принятия решения о том, когда нужно время для развертывания программного обеспечения. Она также отмечает, что размер компании является важным фактором. У средних и крупных компаний может быть бюджет на автоматизацию и для получения необходимых специалистов или по вызову в течение выходных; Однако небольшие компании или стартапы не могут.
Также важно то, какие системы/программное обеспечение создает ваша компания, и когда ваши клиенты используют их больше всего. Она рекомендует избегать развертывания до производства во время пикового использования. Другим важным фактором является критичность изменений, которые вы развертываете. Насколько большое влияние на ваших клиентов, если что -то пойдет не так? Вы также зависите от других сторон для развертывания или тестирования? В настоящее время многие компании интегрируют свои услуги с другими компаниями. Ее точка зрения в том, что, по крайней мере, на данный момент, люди должны всегда храниться в курсе.
Даже имея всю автоматизацию мира, она не рекомендует развернуть что -либо критическое в пятницу, если у вас нет нужных людей с правильными знаниями о том, что развертывается, чтобы проверить это.
Почему терпимость к риску движет решениями о развертывании
Отличный обзор мыслей о оптимальном дне для развертывания программного обеспечения поступает от Юри Федоров, старшего инженера-программиста и инженера по надежности сайта на YouTube. По его мнению, этот вопрос становится в основе серьезной проблемы в технологиях. Простой ответ заключается в том, что ничто не является действительно на 100% надежным, поскольку бесчисленные факторы могут привести к неудаче, и они часто взаимозависимы. Вы можете думать об этом таким образом: сложная система похожа на башню Jenga. Даже если каждый блок (часть программного обеспечения, сервер или процесс) был идеальным, небольшой сдвиг в одной области может привести к разрушению всей башни.
Он предлагает следующий разрыв некоторых факторов, которые способствуют этому отсутствию совершенства:
- Сложность: По мере того, как системы растут, их взаимосвязанные детали (программное обеспечение, аппаратное обеспечение, инфраструктура, зависимости). Изменение в одной области может иметь непредсказуемый волновой эффект на другую.
- Человеческая ошибка: Люди делают ошибки. Будь то ошибка кодирования, неправильный сервер или опечатка в команде, человеческий фактор является постоянным источником потенциального сбоя.
- Внешние ограничения: Ограничения в реальном мире, такие как бюджет, время и знания команды, все влияют на то, как система строится и поддерживается. Иногда необходимо сделать компромисс, который вводит риск.
- Процесс и операции: Даже при лучших намерениях процесс может быть ошибочным. Например, развертывание крупного обновления в пятницу днем может показаться эффективным, но это оставляет мало времени, чтобы исправить что -то, если что -то пойдет не так до выходных. Вот почему многие организации имеют конкретную политику в отношении таких развертываний, выбирая оптимизацию для безопасности над скоростью в определенных сценариях.
Хотя такие подходы, как DevOps, стремятся автоматизировать и снизить многие из этих рисков, они не могут их устранить. Вместо этого они сосредоточены на том, чтобы сделать неудачи менее частыми, легче обнаружить и быстрее восстанавливаться, когда они неизбежно возникают.
Как видите, существует много факторов, которые организация должна учитывать при принятии решения о том, когда развернуть. автоматизация и солидный план отката являются ключом к успеху; Однако необходимо учитывать толерантность к риску и бремя для команды, ответственной за развертывание.
Таким образом, как мы говорим в Octopus, «каждый день — хороший день для развертывания программного обеспечения, даже по пятницам» — до тех пор, пока ваши процессы повторяются и надежны.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Джоанна — CMO в Octopus Deploy. Джоанна имеет более чем 20 -летний опыт работы с маркетингом продуктов как для стартапов программного обеспечения, так и для гигантов программного обеспечения. Узнайте больше от Джоанны Вайганоровской
