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

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

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

  • war / ear files
  • элемент списка
  • свойства файлов
  • sgdb файлы
  • некоторые другие

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

2) Еще я видел, чтобы проверить источники на каждой платформе, а затем установить артефакты моментальных снимков в локальном репозитории. Затем сервер приложений будет использовать эти снимки .папка м2. Нет реального процесса доставки, так как, чтобы поставить новую версию в производство, мы просто должны обновить источники компонентов / webapps, сделать некоторые Maven чистой установки и перезапустить сервер приложений. Я думаю, что это более гибко, но я вижу некоторые недостатки и это подход кажется мне опасным. На этом сайте есть frontoffice, я не знаю номеров, но это намного меньше, чем 1-й. Он также имеет большой backoffice доступный для большинств работников компании 130 000 людей.

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

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

6
git java java-ee maven-2 svn

5 ответов

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

  • разработка на "ПК", что означает в нашем случае Windows -- К сожалению, пока еще Windows Xp -- (и модульное тестирование)
  • непрерывная интеграция и тестирование системы на linux (потому что их дешевле настроить)
  • пре-продукция и продукция на Солярисе (огне Солнца для пример)

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

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

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

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

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

3

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

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

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

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

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

http://wiki.hudson-ci.org/display/HUDSON/M2 + релиз + плагин если вы используете этот плагин и убедитесь, что только сервер 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/ хороший сайт и книги очень хорошие узоры для освобождения.

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

3

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

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

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

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

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

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

  • разработчики изначально разрабатывают на своей локальной машине, ОС свободна в выборе, но мы настоятельно рекомендуем использовать ту же JVM, которая будет использоваться в производстве.
  • у нас есть DEV сервер, на который часто помещаются моментальные снимки кода. Это просто scp из двоичной сборки, созданной из среды IDE. Мы планируем однако для сборки непосредственно на сервере.
  • The DEV сервер используется для заинтересованных сторон, чтобы постоянно заглядывать вместе с развитием. По своей природе нестабильно. Это хорошо известно всем пользователям этого сервера.
  • если код достаточно хорош, он разветвлен и нажат на бета сервер. Опять же, это scp двоичной сборки из IDE.
  • тестирование и общее QA происходит на этом бета сервер.
  • в то время как, если какие-либо аварийные изменения должны быть необходимы для программного обеспечения в настоящее время в производстве, у нас есть третий промежуточный сервер под названием обновление сервер.
  • The обновление сервер изначально используется только для очень небольших исправлений. Здесь мы тоже используем scp скопировать двоичные файлы.
  • ведь тестирование проводится на обновление, мы копируем сборку из обновление to LIVE. Ничто никогда не идет на живые серверы напрямую, оно всегда проходит через сервер обновлений.
  • когда все тестирование будет завершено на бета, тестируемая сборка копируется с бета-сервера на обновление сервер и окончательный раунд тестирования вменяемости выполняется. Поскольку это точная сборка, которая была протестирована на бета-сервере, очень маловероятно, что на этом этапе будут обнаружены проблемы, но мы придерживаемся правила, что все развернутое на живом сервере должно идти через сервер обновлений и что все на сервере обновлений должно быть протестировано перед его перемещением.

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

некоторые из решений, которые мы сделали:

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

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

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

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

1

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

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

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

подробнее в my Непрерывная Доставка разговоры на переговорах:http://parleys.com/#id=2443&st=5

1