Что вы можете сделать, чтобы уменьшить количество ошибок развертывания живого веб-сайта?

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

Как только вы загружаете новую версию, все ломается. Теперь решение проблемы может занять до 20 минут, но общий стресс, который вы терпите, и финансовый и деловой ущерб компании иногда не забываются.

Как уменьшить количество ошибок, возникающих при начальной настройке развертывания новой версии?

PS: Пожалуйста, не упоминайте контрольные списки, потому что они у нас уже есть. Проблема с контрольными списками в том, что они всегда должны обновляться, но не будут.

Две вещи:

• Промежуточная среда, аналогичная живой среде, в которой вы выполняете тестовые развертывания.
• Достаточное тестирование этой среды после развертывания. Автоматизировано и неавтоматизировано.

Есть и другие вещи, которые можно сделать.

Я предлагаю прочитать серию блога из 5 частей об автоматическом развертывании от Troy Hunt. Инструменты, которые он использует, специфичны для MS-стека, но концепции универсальны.

Интересно, почему никто не упомянул Контроль версий - это один из самых важных способов избавить вас от неприятностей при обновлении / обновлении.

Во-первых, ваше развертывание должно быть просто клоном стабильной ветки в вашем хранилище. Все, включая файлы конфигурации, файлы SQL, сценарии установки / обновления, ДОЛЖНЫ управляться версией.

Во-вторых, вам нужно иметь «своего рода» промежуточную область - это может быть что угодно - локальный сервер, временный виртуальный облачный сервер, который вы только что создали, очень простую настройку виртуального хоста или полноценное пользовательское приложение, которое вы поддерживаете вместе с основным приложением. Разница между этой «промежуточной областью» и вашей «областью разработки» заключается в том, что первые более точно моделируют (или имитируют) вашу фактическую среду развертывания. Например, вы можете разрабатывать на PHP 5.3.x с модулем Apache, но поскольку ваш хост - PHP 5.2.x с FCGI, ваша область подготовки должна быть одинаковой.

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

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

Сложность вашей области подготовки должна отражать сложность и объем вашего приложения. Но в любом случае контроль версий незаменим.

Конечно, если вы не используете контроль версий - ничего из этого не применимо - но тогда это так же наивно, как написание базы данных в Logo.

Как предложено, используйте систему постановки . Это дает вам возможность проверить свои изменения в реальной среде.

Это поднимает другой вопрос: есть тестеры . Тестирование того, что я написал сам, не находит столько ошибок, сколько когда кто-то другой тестирует мое приложение.

Другое дело: автоматизируйте процесс развертывания . Выполните миграцию db с помощью ant migrate, автоматически разверните новейшую версию из svn через capistrano и т. Д. При развертывании чего-либо вам не нужно делать больше, чем просто щелчок, и все происходит автоматически. Специально для веб-сайтов, которые нуждаются в некоторой настройке конфигурации, ручные шаги, необходимые для развертывания, являются кошмаром и вероятность того, что что-то пойдет не так, огромна.

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

Для получения бонусных баллов добавьте C и убедитесь, что ваши системы географически разделены, чтобы в результате землетрясения не погибли 2 из них одновременно.

Для многих приложений я признаю, что это излишне.

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

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

Environments
|_property_files
    |_ dev
        |_ com.bla.util
        |    |_ example.properties
        |_ com.bla.beans
        |    |_ someconfig.xml
    |_ test
        ....
    |_ production
        ....
|_database_updates
    |_ dev
        |_ insert_new_static_data.sql
        |_ ...

...

В основном, в моих сценариях сборки и развертывания я беру свойство среды, которое будет извлекать специфичные для среды файлы метаданных, такие как XML-файлы, и заменять их в моем месте сборки перед упаковкой. Далее в моих сценариях развертывания я буду искать любые файлы SQL в обновлениях базы данных и выполнять их в настроенной базе данных для этой среды.

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

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

Расскажите все в вашем вопросе так: они должны всегда обновляться, но они не будут.

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

Короче говоря, более широкое внедрение принципов непрерывной интеграции (CI) поможет избавиться от проблем с производственными выпусками.

1) Сначала разверните на тестовом сайте и проверьте свои изменения

2) Иметь всю конфигурацию в файле конфигурации (веб-конфигурации или аналогичном). Эта конфигурация должна быть специфичной для приложения и никогда не перезаписываться. Любые изменения будут преднамеренными, а не забывать изменить что-то, что должно быть отличным от теста.

В дополнение к превосходным предложениям, приведенным выше, необходимо создать среду для подготовки к работе и использовать автоматизированное тестирование:

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

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

• несколько основных частей, которые меняются медленно и распределяются по всему сайту
• много частей листа, которые могут меняться быстрее, но каждая влияет только на меньшую часть сайта

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

Хорошо выполненный релиз - это все о планировании и коммуникации. Поэтому перед выпуском рассмотрим следующие вопросы:

1. Сколько времени может занять релиз, и есть ли какие-либо риски, позволяющие людям продолжать взаимодействовать с моим продуктом, пока релиз находится в стадии разработки? Если существует риск для системы, рассмотрите возможность перевода системы в автономный режим и размещения вместо нее сообщения «Система в настоящее время проходит техническое обслуживание».

2. Есть ли какие-либо клиенты, которых вам может потребоваться уведомить о выпуске раньше времени? Нужно ли им сообщать о возможном прерывании обслуживания или снижении производительности во время выпуска? Лично я всегда ошибаюсь на стороне чрезмерного общения и рассказываю всем клиентам о предстоящем выпуске или окне обслуживания в публичном блоге или подобном месте.

3. Каковы мои планы на случай непредвиденных обстоятельств, если релиз будет неудачным? Например, если релиз работает плохо, мы должны откатиться и восстановить систему так, как это было до минимума, когда мы находимся в автономном режиме? И если да, хорошо ли задокументированы шаги по откату релиза? Или я должен иметь подходящих людей по вызову или под рукой, чтобы помочь с устранением проблем в случае их возникновения. Лично я думаю, что лучший способ приблизиться к планированию любого релиза - предположить, что с релизом что-то пойдет не так. Таким образом я заставил себя заранее обдумать некоторые из этих вопросов.

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

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

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

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

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

Как последнее слово, иногда самое важное не то, что мы делаем, чтобы предотвратить что-то не так, а то, как мы ведем себя, когда они идут не так. Поэтому я думаю, что важно построить культуру в вашей компании вокруг прозрачности работы. Не пытайтесь скрыть проблемы от клиентов, будьте готовыми. Активно пользуйтесь Твиттером, чтобы информировать клиентов о том, есть ли проблемы, о которых ваша оперативная команда знает в данный момент и работает над их решением ( Lighthouse великолепен в этом!). Подумайте о том, чтобы опубликовать «статусную» страницу для вашего сервиса, на которую клиенты могут сослаться, чтобы увидеть, если что-то не так ( TypePad предлагает отличный пример этого). Итог, всегда ошибаться на стороне чрезмерного общения. Ваши клиенты будут вам благодарны за это.

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

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

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