Я столкнулся с финансовым директором стартапа, который рассказал мне о поставщике, от которого они зависели в выполнении критически важного внутреннего процесса. Он был разочарован тем, что из-за устаревших процессов развертывания вендора, процедур ручного тестирования и регулярных простоев на полдня после каждой новой версии его клиенты и его бизнес были нарушены. Ему нужен был надежный сервис, и впоследствии отношения разорвались.
Серьезной проблемой является предотвращение простоев при одновременном снижении риска подвергнуть пользователей критическим изменениям при развертывании приложений. Я буду опираться на свой опыт в качестве инструктора по разработке программного обеспечения и активного пользователя Heroku, чтобы показать вам, как минимизировать риск развертывания и добиться нулевого времени простоя развертывания. Мы будем использовать приложение Node.js в качестве примера, но эти методы и процедуры можно перенести на приложения, написанные на любом языке, от PHP до Elixir.
Сведение к минимуму риска развертывания и почему это проблема
Риск подвергнуть пользователей критическим изменениям в развернутом приложении невозможно переоценить. В лучшем случае у пользователя будет отрицательный опыт работы с вашим нефункциональным приложением (все еще очень плохо); в худшем случае ошибка может иметь серьезные последствия для безопасности и разрушить доверие пользователей и отношения с клиентами.
К сожалению, ни один процесс не может полностью предотвратить развертывание ошибок. Вы отправите сломанный код. Важно то, как быстро вы сможете выявлять проблемы и устранять их - а еще лучше использовать конвейер непрерывной интеграции и непрерывной доставки (CI / CD) для выявления и диагностики проблем до их развертывания в производственной среде.
Вы можете защитить свое приложение и его пользователей от неработающего кода, проблем с доступностью и проблем с развертыванием, продвигаясь к развертыванию с нулевым временем простоя. Вы также получите преимущество более быстрого процесса развертывания и сокращения времени выполнения заказа от проверки кода до производства за счет автоматизации процесса развертывания. Вот несколько рекомендаций, которым следует следовать при развертывании приложений на Heroku.
Лучшие практики
CI / CD и автоматическое тестирование
Современные операции разработки, поддерживающие гибкие команды разработчиков, требуют CI / CD и автоматизированного тестирования. Независимо от того, что вы используете (Circle CI, Travis, Heroku CI, AWS CodePipeline и т. Д.), Запуск автоматизированного набора тестов как часть процесса развертывания является современной необходимостью и лучшим методом для оптимизации разработки.
Если вы выполняете развертывание на Heroku и используете интеграцию с GitHub, то Heroku CI может запускать набор тестов вашего приложения при каждом развертывании, что позволяет вам легко просматривать результаты тестирования перед объединением или развертыванием критических изменений в вашем приложении. Heroku CI также легко настроить - просто ознакомьтесь с разделами Как использовать Heroku CI или Возможности и функции Heroku CI для получения дополнительной информации.
Heroku CI также поддерживает распределение тестовых прогонов между 32 динамометрическими стенами, чтобы существенно сократить время выполнения.
Несколько динамометрических стендов
Недостаточно просто иметь хорошие инструменты CI - вы должны горизонтально масштабировать свои динамометрические станции, чтобы обеспечить достаточную избыточность, чтобы обеспечить бесперебойную работу, доступность приложений и удобство использования. Поскольку дино работают в цикле каждый день для поддержания стабильности приложения и иногда отключаются для обслуживания, вы должны использовать как минимум два или более дино в производственной среде, чтобы добиться нулевого времени простоя.
В зависимости от требований к пропускной способности вашей службы или приложения вы также можете выполнить вертикальное масштабирование, чтобы обеспечить достаточную резервную емкость. Heroku предоставляет здесь отличные возможности для разработчиков и позволяет масштабировать как по вертикали, так и по горизонтали с помощью простого в использовании интерфейса командной строки.
Обзор приложений
Что может быть лучше для выявления ошибок и критических изменений, чем запуск ваших приложений в безопасной тестовой среде? Просмотр приложений запускает ваш код в новом одноразовом приложении Heroku после успешного запроса на вытягивание GitHub. Каждое приложение для обзора имеет отдельный URL-адрес, которым вы можете поделиться, что делает их отличным способом предлагать, тестировать и комбинировать изменения и модификации в команде разработчиков с нулевым риском. Для каждого запроса на вытягивание вы можете настроить автоматическое создание приложений обзора или создать их вручную.
Чтобы приложение для проверки работало, создайте файл app.json в корне репозитория GitHub вашего приложения. Файл app.json используется для настройки новых приложений, создаваемых при создании запросов на вытягивание. Файл app.json - это мощный инструмент, позволяющий указать наследование значений при подготовке надстроек с использованием плана поставщика надстроек по умолчанию.
Heroku Pipelines
Heroku Pipeline - это набор приложений Heroku с одной и той же кодовой базой. Каждое приложение в конвейере представляет собой один из следующих этапов конвейерной ленты непрерывной доставки: разработка, проверка, постановка и производство.
В отрасли разработки программного обеспечения очевидно и почти повсеместно поддерживается промежуточная среда, параллельная производственной ; конвейеры полезны для управления этим многоэтапным процессом развертывания. Пример рабочего процесса конвейера состоит из следующих этапов:
- Разработчик создает запрос на перенос, чтобы добавить новую функцию или исправить ошибку.
- Затем Heroku автоматически создает приложение для просмотра для запроса на вытягивание, позволяя разработчикам протестировать приложение перед постановкой или производством.
- Если изменение проходит все ручное и автоматическое тестирование, оно объединяется с основной веткой.
- Основная ветвь автоматически развертывается в промежуточном приложении конвейера для дальнейшего тестирования.
- Когда все будет готово, разработчик продвигает тестовое приложение в рабочую среду.
Вот пример схемы конвейера из документации:
Конвейеры управляют только потоком коротких фрагментов кода. Репозиторий Git, переменные конфигурации, надстройки и другие переменные среды вашего приложения должны управляться отдельно. В качестве альтернативы приложения для обзора могут наследовать переменные конфигурации, что является полезной функцией качества жизни.
Продвижение в производство
Окончательная ручная проверка перед продвижением в производство является важной проверкой контроля качества в большинстве случаев автоматизированного процесса. Люди могут уловить то, что ускользает даже от самых надежных автоматизированных процедур тестирования, поэтому важно не полностью отделять человеческий надзор в погоне за эффективностью автоматизации. Кроме того, гораздо интереснее иметь кого-то конкретного, кто виноват, когда что-то идет не так (шутка - посмотрите Удивительный доклад Николаса Минса о системных сбоях в сложных автоматизированных системах и о том, как их избежать, создавая психологическую безопасность в вашей команде).
Из интерфейса командной строки вы можете продвигать слаг с помощью следующей команды (команда должна указывать имя (с флагом (-a) или Git remote с флагом (-r)) исходного приложения):
$: heroku pipelines: продвигать -r постановка
Полный список команд конвейера с подробностями использования доступен с:
$: heroku help конвейеры
Релизные задачи (миграции)
Функция фазы выпуска Heroku позволяет выполнять определенные задачи перед развертыванием приложения. Если задача фазы выпуска завершается неудачно, новый выпуск не развертывается, поэтому текущий выпуск не затрагивается и, таким образом, снижается риск развертывания критического изменения. Этап выпуска может быть полезен для таких задач, как отправка CSS, JS и других ресурсов из служебного файла приложения в корзину CDN или S3, подготовка или аннулирование хранилищ кеша или выполнение миграции схемы базы данных.
Важно отметить, что релиз, слаг и приложение для обзора - это разные идеи в контексте архитектуры Heroku (для ясности обязательно обратитесь к высокоуровневому техническому описанию того, как работает Heroku). Команда выпуска запускается в одноразовом динамометрическом стенде всякий раз, когда создается новый выпуск, если только выпуск не вызван изменениями в переменных конфигурации надстройки.
Следующие события создают новый выпуск:
- Успешная сборка приложения
- Изменение значения переменной конфигурации (если конфигурационная переменная не связана с надстройкой)
- Конвейерное продвижение
Определите задачи выпуска в вашем Procfile:
выпуск: ./release-tasks.sh
Предварительная загрузка
Помощь! Мое приложение загружается медленно и делает его недоступным во время перезапуска дино. Предварительная загрузка - это решение. Вместо остановки существующего набора веб-серверов перед запуском новых, предварительная загрузка запускает новые веб-серверы (и позволяет им получать трафик) до того, как будут остановлены существующие.
Чтобы включить бег:
$: heroku features: enable -a предварительная загрузка myapp
При использовании этой функции существует ряд потенциальных ловушек, поэтому обязательно ознакомьтесь с предупреждениями о предварительной загрузке перед ее использованием. Например, когда вы делаете выпуски с предварительной загрузкой, у вас будет одновременно работать две версии вашего кода (перекрытие до 3 минут), хотя только одна версия будет обслуживать запросы пользователей. Это потенциально может вызвать проблемы с внешними службами и некоторыми надстройками Heroku.
Мониторинг производства и APM
Отличный DevOps не останавливается только на развертывании. Heroku предлагает встроенные метрики приложений вместе с сотнями надстроек на своем рынке, которые упрощают настройку мониторинга для ваших приложений в производственной среде. Используйте службы управления производительностью приложений (APM), такие как New Relic и AppOptics, для быстрого выявления и устранения проблем.
Команды DevOps (или группы разработчиков) могут отслеживать частоту ошибок, регистрировать задержки и пропускную способность для конкретных компонентов, а также обнаруживать ошибки / сбои и условия, которые к ним привели. Другие инструменты мониторинга, регистрации и диагностики ошибок, такие как Pingdom, Papertrail, Rollbar и StillAlive, также являются доступными надстройками в экосистеме Heroku. Эти инструменты приносят пользу любому производственному приложению и команде, стремящейся улучшить свой продукт или быстро решить проблемы, когда что-то пойдет не так.
Заключение
Развертывание с нулевым временем простоя, обеспечиваемое плавным и безболезненным процессом CI / CD, должно быть целью для большинства сложных производственных приложений. Примените эти передовые практики, чтобы помочь своей команде создать отличную среду для пользователей (и разработчиков).
