Каково лучшее решение для обработки мультиплатформенной разработки (dev / integra / valid / prod ...) Процесс доставки

Question

Я не такой опытный, но я работал над некоторыми крупными проектами Java EE (используя maven2) с совершенно разными способами для установки / доставки на разных платформах.

1) Одним из них былоиспользуйте снимки для разработки, а затем сделайте релиз maven из компонентов и основных веб-приложений.Таким образом, поставка:

• файлы войны / уха
• Элемент списка
• файлы свойств
• файлы sgdb
• некоторые другие

И команды будут использовать эти файлы для размещения новых версий приложений на разных платформах.Я думаю, что этот процесс является строгим и позволяет вам всегда легко сохранять различные конфигурации, переданные в производство, но он не очень гибкий, процесс немного тяжелый и заставляет нас иногда делать некоторые грязные вещи, такие как переопределение класса войны, чтобыпатч регрессии ... Это веб-сайт электронной коммерции с 10 миллионами уникальных посетителей в месяц и доступностью 99,89%.

2) Еще один вариант, который я видел, это проверить источники на каждой платформе и затем установить артефакты снимковв локальном хранилище.Затем сервер приложений будет использовать эти снимки папки .m2.Реального процесса доставки не существует, поскольку чтобы запустить новую версию в производство, нам просто нужно обновить исходные коды компонентов / веб-приложений, выполнить maven clean и перезапустить сервер приложений.Я думаю, что это более гибко, но я вижу некоторые недостатки, и этот подход кажется мне опасным.Этот сайт имеет фронт-офис, я не знаю номера, но он намного меньше, чем первый.Он также имеет большой резервный офис, доступный большинству сотрудников компании из 130 000 человек.

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

Я здесь не для того, чтобы спросить, какое решение является лучшим, но задаюсь вопросом, видели ли вы разные вещи, и какую стратегию вы бы использовали в этом случае?

Answer 1

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

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

• Выполните экстернализацию любой конфигурации, чтобы один и тот же встроенный артефакт мог работать во всех ваших средах.Затем создавайте артефакты только один раз для каждого выпуска. Восстановление для различных сред занимает много времени и сопряжено с риском, например, это не то приложение, которое вы тестировали
• Централизовать место, где создаются артефакты.- например, все войны для производства должны быть упакованы на сервере CI (использование плагина maven release для hudson хорошо работает для нас).
• Все изменения для релиза должны отслеживаться (контроль версий,таблица аудита и т. д.), чтобы обеспечить стабильность и возможность быстрого отката и диагностики.Это не означает тяжелый процесс - см. Следующий пункт
• Автоматизируйте все, создавая, тестируя, выпуская и откатывая.Если процесс надежный, автоматизированный и быстрый, один и тот же процесс можно использовать для всего: от быстрых исправлений до экстренных изменений.Мы используем тот же процесс для быстрого 5-минутного экстренного исправления и для основного выпуска, потому что он автоматизирован и быстр.

Некоторые дополнительные указатели:

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

http://wiki.hudson -ci.org / display / HUDSON / M2 + Release + Плагин Если вы используете этот плагин и убедитесь, что только только CI-сервер имеет правильные учетные данные для выполнения maven-релизов, выможет гарантировать, что все выпуски выполняются последовательно.

http://decodify.blogspot.com/2010/10/how-to-build-one-click-deployment-job.html Простой способ развертывания ваших выпусков.Хотя для больших сайтов вам, вероятно, понадобится что-то более сложное, чтобы не было простоев - например, развертывание до половины кластера за раз и переворачивание веб-трафика между двумя половинами - http://martinfowler.com/bliki/BlueGreenDeployment.html

http://continuousdelivery.com/ Хороший сайт и книга с некоторыми очень хорошими шаблонами для выпуска.

Надеюсь, это поможет - удачи.

Answer 2

Не занимаясь деликатными веб-сайтами, мне пришлось участвовать в процессе управления релизами для различных крупных (Java) проектов в гетерогенной среде:

• разработка на «ПК», то есть в нашем случае Windows -к сожалению, пока Windows Xp - (и модульное тестирование)
• непрерывная интеграция и тестирование системы на linux (потому что они дешевле в настройке)
• подготовка и выпуск на Solaris (Sun Fireнапример)

Обычный метод, который я видел, был:

• двоичная зависимость (каждый проект использует двоичные файлы, созданные другим проектом, а не их источники)
• нет перекомпиляции для интеграционного тестирования (файлы jar, созданные на ПК, непосредственно используются на фермах linux)
• полная перекомпиляция на этапе подготовки (имеется в виду бинарный файл, хранящийся в репозитории Maven), по крайней мере, чтобы убедиться, что все перекомпилируется с тем же JDK и опциями продажи.
• без VCS (Система контроля версий, как SVN, Perforce, Git, Mercurial, ...) в производственной системе: все развертывается от pre-prod до rsynch.

---

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

• Когда вы разрабатываете свой проект, вы зависите напрямую от источников или двоичных файлов других проектов?
• Где вы храните значения настроек?
  Параметризируете ли вы их?и, если да, когда вы заменяете переменные их окончательными значениями (только при запуске или также во время выполнения?)
• перекомпилируете ли вы все в конечной (подготовительной) системе?
• Как получить доступ / скопировать / развернуть в своей производственной системе?
• Как остановить / перезапустить / исправить ваши приложения?

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

Answer 3

Я большой сторонник единого развертывания, содержащего все (Code, Config, DB Delta, ...) для всех сред , построенного и выпущенного централизованно на сервере CI .

Основная идея заключается в том, что Code, Config и DB Delta в любом случае тесно связаны . Код зависит от определенных свойств, устанавливаемых в конфигурации, и некоторых объектов (таблиц, представлений, ...), присутствующих в БД. Так зачем разделять это и тратить свое время на отслеживание всего, чтобы убедиться, что оно совмещается, когда вы можете просто отправить его вместе в первую очередь.

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

Подробнее в моей Непрерывной доставке Обсуждение в Parleys: http://parleys.com/#id=2443&st=5

Answer 4

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

• Разработчики изначально разрабатывают на своем локальном компьютере, ОС может выбирать сами, но мы настоятельно рекомендуем использовать ту же JVM, которая будет использоваться в производстве.
• У нас есть сервер DEV , на который часто отправляются моментальные снимки кода. Это просто scp из двоичной сборки, созданной из IDE. Мы планируем построить прямо на сервере, хотя.
• Сервер DEV используется заинтересованными сторонами для постоянного ознакомления с разработкой. По самой своей природе это нестабильно. Это хорошо известно всем пользователям этого сервера.
• Если код достаточно хорош, он разветвляется и отправляется на сервер BETA . Опять же, это scp двоичной сборки из IDE.
• На этом сервере BETA проводится тестирование и общий контроль качества.
• В то же время, если для программного обеспечения, которое в настоящее время находится в производстве, необходимы какие-либо экстренные изменения, у нас есть третий промежуточный сервер, который называется UPDATE server.
• Сервер UPDATE изначально используется только для внесения очень небольших исправлений. Здесь также мы используем scp для копирования двоичных файлов.
• После того, как все тестирование проведено в ОБНОВЛЕНИЕ , мы копируем сборку из ОБНОВЛЕНИЕ в LIVE . Ничто никогда не отправляется на действующие серверы напрямую, оно всегда проходит через сервер обновлений.
• Когда все тестирование завершено на BETA , протестированная сборка копируется с бета-сервера на сервер UPDATE и выполняется последний раунд проверки работоспособности. Поскольку именно эта сборка была протестирована на бета-сервере, маловероятно, что на этом этапе будут обнаружены проблемы, но мы придерживаемся правила, согласно которому все, что развернуто на живом сервере, должно проходить через сервер обновлений и что все в обновлении сервер должен быть проверен перед его перемещением.

Эта скользящая стратегия позволяет нам разрабатывать для 3 версий параллельно. Версия N, которая в настоящее время находится в производстве и подготовлена ​​через сервер обновлений, версия N + 1, которая будет следующим основным выпуском, которая должна быть выпущена и находится на бета-сервере, и версия N + 2, которая является следующим следующим выпуском для которого в настоящее время ведутся разработки и они размещаются на сервере разработки.

Некоторые из сделанных нами выборов:

• Полное приложение (EAR) обычно зависит от артефактов из других проектов. Мы решили включить двоичные файлы этих других проектов, а не собирать все это из исходного кода. Это упрощает сборку и дает большую уверенность в том, что тестируемое приложение связано с точно правильными версиями всех его зависимостей. Цена заключается в том, что исправление в такой зависимости должно распространяться вручную среди всех приложений, которые зависят от него.
• Конфигурация для каждой стадии встроена в EAR. В настоящее время мы используем соглашение об именах, и скрипт копирует правильную версию каждого файла конфигурации в нужное место. Параметризация пути для каждого файла конфигурации, например, в настоящее время рассматривается возможность использования одного заполнителя {stage} в корневом конфигурационном файле. Причина, по которой мы сохраняем конфигурацию в EAR, заключается в том, что разработчики являются теми, кто представляет и зависит от конфигурации, поэтому именно они должны отвечать за ее поддержку (добавление новых записей, удаление неиспользуемых, настройка существующих и т. Д.).
• Мы используем стратегию DevOps для группы развертывания. Он состоит из человека, который является чисто разработчиком, двух человек, которые являются одновременно разработчиком и оператором, и двух человек, которые являются исключительно оператором.

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

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

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

Answer 5

Чтобы добавить к моему предыдущему ответу, в основном вы сталкиваетесь с проблемой CM-RM:

• CM (Управление изменениями)
• RM (Управление выпусками)

Другими словами, после первого выпуска (т. Е. Основная начальная разработка завершена) вы должны продолжать делать выпуск, и именно этим CM-RM должен управлять.

Реализация RM может быть или 1) или 2) в вашем вопросе, но я хотел бы добавить к этому механизму:

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