6 лучших практик для развертывания приложений


Разверните приложения плавно с этими советами

Многие команды разработчиков программного обеспечения сейчас работают Agile / Scrum, и это здорово! Одним из краеугольных камней гибкого способа работы является «Доставляйте ценность быстро и часто», Реальное значение предоставляется только тогда, когда программное обеспечение запущено в производство (не Dev, не QA J).

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

Вам также может понравиться: Развернуть свое приложение в один клик

DeBuild Раз развернуть в любом месте

Вы сталкиваетесь с такими ситуациями, как «Эй! Он работает на QA, но не на UAT или Prod ». Одна из основных причин таких ситуаций – создание артефактов сборки для каждой среды. Ключевым является продвижение того же пакета, который был протестирован в более низких средах (Dev / QA), в более поздние среды (UAT / Prod).

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

намек: Используйте один и тот же пакет сборки и распространяйте его во всех средах.

Это должен быть первый процесс для людей

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

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

намекУлучшение сотрудничества между Dev и Ops для минимизации хэндоверов.

Сделать развертывания скучными

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

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

Автоматизировать, Автоматизировать, Автоматизировать

Автоматизируйте процесс сборки, автоматизируйте конфигурацию приложения / компонента (конфигурация как код), автоматизируйте свою инфраструктуру (инфраструктура как код), автоматизируйте процесс развертывания. Хорошее правило: «Все, что не требует человеческого суждения / вмешательства, является кандидатом на автоматизацию».

Подсказка: Визуализируйте свой текущий процесс сквозного развертывания и идентифицируйте быстрые победы и низко висящие плоды для автоматизации или выявления узких мест.

Архитектура управляет строительством

Размер партии оказывает большое влияние на поток, а архитектура влияет на размер партии. Если вы измените или добавите одну строку кода, насколько велико влияние на тестирование, сборку и развертывание пакета? Следуйте стандартным принципам проектирования, таким как разделение интересов, принцип единой ответственности, принцип наименьшего знания, не повторяйте себя и минимизируйте предварительный дизайн. Как показано ниже, если у вас архитектура спагетти, развертывание изменений дорого и занимает много времени, поэтому выбирайте Ravioli

Подсказка: Выберите слабосвязанную архитектуру и постоянно сосредотачивайтесь на рефакторинге архитектуры

Управляйте своими зависимостями

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

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

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

Дальнейшее чтение

Следующее поколение развертываний приложений Java

Лучшее развертывание приложений благодаря автоматизации инфраструктуры

Руководство DZone по контейнерам: разработка и управление