Как я могу автоматизировать производственные развертывания, не испытывая особого беспокойства?

В нашем магазине мы используем SVN для управления исходным кодом и CruiseControl для CI для обработки автоматических сборок и развертываний в наших средах разработки, тестирования и интеграции.

Все это работает гладко, однако из-за аппаратных и ресурсных ограничений наша среда интеграции не является средой с балансировкой нагрузки на 2 сервера, как наша производственная среда. В то время как все остальное одинаково, это будет единственная разница между нашей интеграцией и производственной средой (хотя и большой!)

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

Я вообще не фанат контроля, но я всегда чувствую жадную необходимость развертывать производство вручную. Я слышал от коллег, что это, как правило, Really BAD Thing ™, но они не смогли доказать это.

Я знаю, что когда я делаю это вручную, я вижу, что я физически копирую правильные файлы, я физически выключаю серверы приложений и гарантирую, что они успешно закрылись, я физически запускаю резервные копии серверов и затем физически проверяю журналы, чтобы сделать уверен, что все в порядке, и развертывание прошло успешно. Это дает мне душевное спокойствие.

Какие аргументы против этого аргумента ИЛИ для автоматического развертывания сценариев?

Есть несколько очевидных аргументов против этого.

1. Что произойдет, если вы уйдете. Вся эта информация тщательно документирована, или это в основном в вашей голове. Автоматизированные сценарии - намного лучшее место для кого-то еще, чтобы взять на себя.

2. Все совершают ошибки. Придет время, когда человек, занимающийся развертыванием, устал, не обращая внимания ни на что. Да, в идеале развертывание выполняется только в счастливом спокойном месте с большим количеством времени. На практике их можно спешить и подчеркивать при попытке выкрутить срочные исправления. Это наиболее вероятное время, чтобы сделать ошибку, а также наиболее дорогостоящее. Если развертывание является одним сценарием, то вероятность ошибок ограничена.

3. Время. По мере усложнения развертываний количество, которое нужно сделать, увеличивается. Сценарии просто требуют запуска, ручной проверки, а затем ручного переключения (вы также можете автоматизировать это, но я разделяю некоторую паранойю :).

Вы можете получить лучшее из лучшего: спокойствие с проверкой процессов и надежность автоматизации.

Сценарий развертывания. Затем пройдите и вручную проверьте, запущены ли процессы, удалены ли файлы и т. Д. Другими словами, напишите свой собственный сценарий QA, чтобы убедиться, что автоматизированные шаги 1 - X действительно произошли.

Я думаю, что ключевой момент здесь: почему вы думаете, что не можете написать сценарий процесса проверки?

Мои сценарии развертывания не просто загружают архивы и перезапускают сервисы. Они распечатывают много информации с цветовой кодировкой на каждом этапе развертывания и в конце предоставляют мне сводку событий. Это позволяет мне знать, что процессы запущены и работают, что домашняя страница обслуживает 200 кодов состояния и что все машины и службы могут хорошо видеть друг друга. Затем у меня есть отдельный сервис, который не является частью скрипта, который отслеживает файлы журналов, ошибки уровня 4xx и 5xx и ключевые метрики сайта. Затем он начинает кричать на меня через любую возможную среду (электронная почта, текстовые сообщения и сигналы тревоги), если есть резкие пики негативного эффекта.

Между этим и CI-серверами, на которых выполняются тесты, я буквально разворачиваюсь и забываю об этом уровне автоматизации. Я даже не просматриваю ни одной страницы на сайте после пуша из-за того, насколько надежен сейчас этот процесс, что позволяет мне не только выполнять развертывание так часто, как я хочу, но позволяет новому разработчику в проекте обновлять живую версию сайт в течение нескольких минут после прибытия на борт. В прошлом я даже делал автоматическое развертывание серверов CI в рабочей среде после фиксации в ветке master / trunk, которая пропускает все. Вот как я уверен в своих инструментах.

Тебе тоже должно быть.

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

Если что-то пойдет не так, он должен пройти надлежащие процедуры отката и отправить вам сообщение. Все, что происходит, может быть зарегистрировано на потом. Вы можете управлять версиями сценариев и устанавливать тестовые случаи.

Но если вы запускаете команды вручную, у вас нет ни одного из этих преимуществ. Вместо этого у вас есть список недостатков.

• У вас нет хорошего журнала, история оболочки не считается
• Никто не знает, как это сделать
• Шаги пропускаются
• Проверки проводятся только иногда
• Некоторые элементы для развертывания могут быть пропущены, я делал это раньше
• Это займет намного больше времени
• Вы можете быть прерваны во время процесса

Подходящий скрипт должен быть почти таким же, как если бы вы печатали все на оболочке. Это одна из причин, по которой у нас есть скрипты bash. Если вы доверяете тому, что делаете, почему вы не можете все записать и подтянуть? Лучшая проверка, более быстрая проверка, больше проверки может произойти, потому что компьютер делает это.

Я могу понять, что немного нервничаю, пытаясь что-то новое в среде prod. Будучи опасаться потенциальной катастрофы является хорошая вещь ^ТМ .

Автоматизированные сценарии - это также Good Thing ^TM, и если вы тщательно к ним подходите, вы сможете минимизировать опасность и снизить страх. Так что мой совет таков;

• Подготовьте (и попрактикуйтесь в env интеграции) контрольный список / набор тестов, чтобы вы могли быстро выяснить, работает ли он и что, если что-то пойдет не так. Подробная регистрация может помочь с этим.
• Резервное копирование всего. Подготовьте и попробуйте выполнить откат вручную, чтобы вы могли восстановиться, если он идет неправильно.
• Протестируйте как можно больше, прежде чем делать это по-настоящему на Prod. Похоже, вы хорошо справляетесь с этим в своей среде интеграции.
• В первый раз, когда вы попробуете это, сделайте это с низким профилем, с низким изменением воздействия. Что-то вроде незначительного обновления или патча. Идея состоит в том, чтобы свести к минимуму выпадение, если оно пойдет не так. Не выбирайте крупное обновление (где наблюдают генеральный директор и все ваши конкуренты) для первого запуска.

После нескольких успешных запусков ваша уверенность возрастет, и вскоре вы удивитесь, как вам удавалось выполнять развертывание вручную.

Вот самый большой аргумент против ручного развертывания в производство: вы человек и будете делать ошибки. Несомненно, будут времена, когда вы забудете сделать что-то, что вызовет у вас горе. Хорошо написанное автоматическое развертывание не имеет такой же тенденции. Это правда, что у вас все еще могут быть испорченные производственные развертывания, но это потому, что в вашем автоматизированном развертывании есть ошибки, которые необходимо устранить.

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

Тем не менее, вот несколько ключевых указателей для автоматизации ваших производственных развертываний:

• Не делай все сразу! Начните медленно писать свои автоматизированные развертывания. Сначала настройте отдельную непроизводственную среду и попробуйте автоматизировать развертывание там. Как только вы приобрели уверенность в своих автоматизированных развертываниях, вы можете начать думать о развертывании продукции
• Начните выпускать и развертывать очень часто! Автоматическое развертывание намного проще, если у вас нет 4 месяцев кода, ожидающего выпуска. Выпускать небольшие функции и исправлять ошибки несколько раз в неделю. Преимущества этого стиля выпуска не могут быть преуменьшены!
• Положитесь на автоматизированные тесты, чтобы убедиться, что ваша производственная среда будет работать. Опять же, на это нужно время, но это очень важно. Автоматизированные тесты всегда лучше ручных приемочных испытаний. Конечно, ручные приемочные тесты - это хорошо, но автоматические тесты могут помочь вам определить, следует ли вам внедрять их в производство или нет. Они являются ключом, который позволяет весь этот процесс автоматизированной, непрерывной доставки. Если ваши тесты не пройдены, вы не знаете, внедрять ли их в производство.

Запустите скрипты на живом сервере. Он будет работать, и после того, как вы несколько раз увидели, что он работает нормально, вы будете в этом абсолютно уверены.

Если серьезно, вы, скорее всего, совершите ошибки, чем сценарий развертывания.

Компьютеры не делают ошибок, люди делают.

Напишите свой сценарий один раз и тщательно проверьте его, пройдитесь по нему строка за строкой. С этого момента вы можете быть уверены, что при каждом развертывании это будет работать.

Сделайте это вручную, и вы обязательно совершите ошибки. Может быть, вы написали, все, что вам нужно сделать, вниз, но это так легко ошибиться. Вы должны скопировать все файлы, кроме файла web.config? Вы можете поспорить, что когда-нибудь вы перезапишете это. Сценарий никогда не сделает эту ошибку.

Как я могу автоматизировать производственные развертывания, не испытывая особого беспокойства?

Чрезвычайное беспокойство, которое вы испытываете при автоматизации производственных развертываний, скорее всего, основано на двух убеждениях:

1. Однажды или другой, на каком-то этапе развертывания произойдет сбой, и вы или другой человек сможете быстро восстановиться после сбоя, в то время как автоматический сценарий может пропустить его.

2. Упущенный сбой в производстве имеет драматические последствия.

Мало что можно сделать с 2., кроме того, чтобы избежать сбоев, поэтому давайте сосредоточимся на 1.

Дешевое решение, слегка улучшающее существующий, - это использование полуавтоматической процедуры развертывания, ожидающей проверки в конце каждого шага установки. Полуавтоматическое решение позволит вам воспользоваться преимуществами полностью автоматического решения, такими как согласованность и воспроизводимость, в то же время у вас будет возможность отслеживать прогресс и восстанавливаться после ошибок, к которым вы привыкли.

Полуавтоматический сценарий и его биотоп (регрессионные тесты и т. Д.) Также могут служить средством получения знаний о сбоях, возникающих в процессе установки, и способах их устранения.

Что мне нравится, так это то, что вы можете протестировать развертывание на стадии или QA и знать, что когда вы запустите его на prod, произойдут те же самые шаги.

Когда вы делаете это вручную, легче забыть шаг или сделать их не по порядку.

... из-за аппаратных и ресурсных ограничений наша среда интеграции не является средой с балансировкой нагрузки на 2 сервера, как наша производственная среда. В то время как все остальное одинаково, это будет единственная разница между нашей интеграцией и производственной средой (хотя и большой!)

Учитывая вышеизложенное, я, вероятно, буду так же обеспокоен, как и вы.

Однажды я провел обзор и тестирование автоматизированного сценария, который развертывается на SLB, и мне кажется, что без предварительного тестирования при настройке с балансировкой нагрузки я бы предпочел сделать что-то вручную.

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

• В одном из проектов я помогал им в развертывании в качестве представителя команды разработчиков. До развертывания они просматривали мои инструкции, и во время развертывания я просто сидел в сети, готовый проконсультироваться, если что-то пойдет не так. Тогда я научился ценить это разделение .
   
  Не то чтобы они были быстрее (зачем они? Я тестировал развертывания в 5-10 раз чаще, чем они). Большая разница была в фокусе. Я имею в виду, моя голова всегда загружена "основными" вещами - кодированием, отладкой, новыми функциями - слишком много отвлекающих факторов, чтобы должным образом сконцентрироваться на развертывании. В отличие от этого, их основным материалом было только техническое обслуживание производства, и они были сосредоточены на этом.
   
  Удивительно, насколько лучше работает мозг, когда он сфокусирован. Эти ребята, они были намного внимательнее, они сделали намного меньше ошибок, чем я. Они просто знали это лучше меня. Они даже научили меня одной или двум вещам, которые облегчили мои собственные тестовые развертывания.

Создайте сценарий развертывания, который вы используете для перемещения вашего кода в любую среду. Мы используем точно такой же процесс развертывания для перемещения кода в dev, qa, staging и наконец в производство. Поскольку мы выполняем развертывание несколько раз в день в dev и ежедневно в QA, мы обрели уверенность в правильности сценариев развертывания. В основном, проверяйте его, используя его часто.

1. Упростить. Ваш процесс изменения должен быть rsync-файлами, запускать SQL-скрипт и ничего более.
2. Автоматизировать.
3. Тест.

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

Вам по-прежнему необходимо иметь план отмены, как и для любых изменений в любом контексте, и он также должен быть автоматизирован.

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

Полностью возможно использовать сценарии автоматизации для развертывания в производственных средах. Однако, чтобы сделать это надежно, вам нужно уметь делать несколько вещей.

1. Надежно откат на предыдущую версию.
2. Получите положительное подтверждение того, что развертывание было успешно применено и отвечает на действительный трафик.
3. Иметь сопоставимые среды для разработки и QA, которые также используют те же сценарии.

У сценариев есть некоторые преимущества, например, они никогда не пропустят команду, потому что ее 2 часа ночи и она устала.

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

Вот почему важно, чтобы после запуска сценария также выполнялась определенная фаза тестирования, которая проверяет, что новое развертывание запущено, выполняется и обрабатывает запросы, прежде чем включится живой трафик.

1. возьмите большее окно для развертывания в первый раз, если что-то пойдет не так

2. Разделите процесс развертывания на две части. а. Резервное копирование (вручную) - это должно дать вам уверенность, если что-то пойдет не так во время развертывания

   б. Развертывание (автоматизированная)

как только вы сможете развернуть с уверенностью в первый раз. Вы также можете автоматизировать процесс резервного копирования.