Какое лучшее решение для обработки мультиплатформенной (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 людей.
Я думаю, в зависимости от веб-сайта, его экспозиции для общественности и требуемой доступности, мы должны адаптировать стратегию доставки к потребностям.
Я здесь не для того, чтобы спросить, какое решение является лучшим, но интересно, если вы видели разные вещи, и что стратегия, которую вы бы использовали в этом случае?
5 ответов
Не имея дело с веб-сайтами, я должен был участвовать в процессе управления выпуском для различных больших (Java) проектов в гетерогенной среде:
- разработка на "ПК", что означает в нашем случае Windows -- К сожалению, пока еще Windows Xp -- (и модульное тестирование)
- непрерывная интеграция и тестирование системы на linux (потому что их дешевле настроить)
- пре-продукция и продукция на Солярисе (огне Солнца для пример)
общий метод, который я видел, был:
- двоичная зависимость (каждый проект использует двоичные файлы, созданные другим проектом, а не их источники)
- нет перекомпиляции для интеграционного тестирования (банки, производимые на ПК, непосредственно используются на фермах linux)
- полная перекомпиляция на предварительном производстве (имеется в виду двоичный файл, хранящийся в репозитории Maven), по крайней мере, чтобы убедиться, что все перекомпилируется с тем же JDK и варианты продажи.
- нет VCS (система управления версиями, как SVN, Perforce, Git, Mercurial,...) на производственной системе: все развернуто от pre-prod через rsynch.
таким образом, различные параметры для учета процесса управления выпуском:
- когда вы разрабатываете свой проект, вы напрямую зависите от источников или двоичных файлов других проектов?
- где вы храните настройки ценности?
Вы параметризовать их и, если да, когда вы замените переменные по их конечные значения (только при запуске, или во время выполнения?) - вы перекомпилируете все в финальной (предпроизводственной) системе?
- как получить доступ / копировать / развернуть в вашей производственной системе?
- как вы останавливаете / перезапускаете / исправляете свои приложения?
(и это не исчерпывающий список.
В зависимости от характера выпуска приложения, другие проблемы должны быть решены)
ответ на это сильно варьируется в зависимости от точных требований и командных структур.
я реализовал процессы для нескольких очень больших веб-сайтов с аналогичными требованиями к доступности, и есть некоторые общие принципы, которые я нахожу, работали:
- 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/ хороший сайт и книги очень хорошие узоры для освобождения.
надеюсь, это поможет - удачи.
чтобы добавить к моему предыдущему ответу, то, с чем вы имеете дело, в основном проблема CM-RM:
- CM (Управление изменениями)
- RM (управление выпуском)
другими словами, после первого выпуска (т. е. основная начальная разработка закончена) вы должны продолжать выпуск, и именно этим CM-RM должен управлять.
реализация RM может быть либо 1), либо 2) в вашем вопросе, но моя точка зрения заключалась бы в том, чтобы добавить к этому механизм:
- правильный CM, чтобы отслеживать любой запрос на изменение и оценивать их влияние, прежде чем совершать какие-либо разработки
- правильный RM для того, чтобы иметь возможность реализовать тесты "release" (система, производительность, регрессия, тесты развертывания), а затем планировать, планировать, выполнять, а затем контролировать сам релиз.
не утверждая, что это лучшие решение, вот как моя команда в настоящее время выполняет постановку и развертывание.
- разработчики изначально разрабатывают на своей локальной машине, ОС свободна в выборе, но мы настоятельно рекомендуем использовать ту же JVM, которая будет использоваться в производстве.
- у нас есть DEV сервер, на который часто помещаются моментальные снимки кода. Это просто
scp
из двоичной сборки, созданной из среды IDE. Мы планируем однако для сборки непосредственно на сервере. - The DEV сервер используется для заинтересованных сторон, чтобы постоянно заглядывать вместе с развитием. По своей природе нестабильно. Это хорошо известно всем пользователям этого сервера.
- если код достаточно хорош, он разветвлен и нажат на бета сервер. Опять же, это
scp
двоичной сборки из IDE. - тестирование и общее QA происходит на этом бета сервер.
- в то время как, если какие-либо аварийные изменения должны быть необходимы для программного обеспечения в настоящее время в производстве, у нас есть третий промежуточный сервер под названием обновление сервер.
- The обновление сервер изначально используется только для очень небольших исправлений. Здесь мы тоже используем
scp
скопировать двоичные файлы. - ведь тестирование проводится на обновление, мы копируем сборку из обновление to LIVE. Ничто никогда не идет на живые серверы напрямую, оно всегда проходит через сервер обновлений.
- когда все тестирование будет завершено на бета, тестируемая сборка копируется с бета-сервера на обновление сервер и окончательный раунд тестирования вменяемости выполняется. Поскольку это точная сборка, которая была протестирована на бета-сервере, очень маловероятно, что на этом этапе будут обнаружены проблемы, но мы придерживаемся правила, что все развернутое на живом сервере должно идти через сервер обновлений и что все на сервере обновлений должно быть протестировано перед его перемещением.
эта сползая стратегия позволяет нам превратиться для 3 версий параллельно. Версия N, которая в настоящее время находится в производстве и поставлена через сервер обновлений, версия N+1, которая будет следующей крупной версией, которая будет выпущена и поставлена на бета-сервере, и версия N+2, которая является следующей-следующей крупной версией, для которой разработка в настоящее время ведется и ставится на на Дев сервере.
некоторые из решений, которые мы сделали:
- полное приложение (EAR) обычно зависит от артефактов из других проектов. Мы решили включить двоичные файлы этих других проектов вместо того, чтобы строить все это из источника. Это упрощает построение и дает большую уверенность в том, что тестируемое приложение поставляется с точными версиями всех его зависимостей. Стоимость это исправить в такой зависимости вручную распространяется на все приложения, которые от него зависят.
- конфигурация для каждой постановки встроена в ухо. В настоящее время мы используем соглашение об именах, и сценарий копирует правильную версию каждого файла конфигурации в нужное место. В настоящее время рассматривается параметризация пути для каждого файла конфигурации, например, с помощью одного заполнителя {stage} в корневом файле конфигурации. Причина, по которой мы храним конфигурацию в ухе, заключается в том, что разработчики являются теми, кто вводит и зависит от конфигурации, поэтому они должны отвечать за ее поддержание (добавление новых записей, удаление неиспользуемых, настройка существующих и т. д.).
- мы использовать DevOps стратегия для группы развертывания. Он состоит из лица, которое является чисто разработчиком, двух лиц, которые являются как разработчиком, так и операциями, и двух лиц, которые являются чисто операциями.
встраивание конфигурации в ухо может быть спорным, так как традиционно операции должны иметь контроль, например, над источниками данных БД, используемыми в производстве (на какой сервер он указывает, сколько соединений разрешено иметь пулу соединений и т. д.). Однако, поскольку у нас есть люди в команде разработчиков, которые также работают, Они легко могут проверить изменения, внесенные другими разработчиками в конфигурацию, пока код все еще находится в разработке.
параллельно с этапом у нас есть сервер непрерывной сборки сервера, выполняющий сценарий (ANT) строится после каждой регистрации (максимум один раз в 5 минут) и выполняет модульные тесты и некоторые другие тесты целостности.
остается трудно сказать, является ли это лучшие подход и мы постоянно пытаемся улучшить наш процесс.
Я большой сторонник один развертываемый, содержащий все (код, конфигурация, Дельта БД,...) для всех сред, построенный и выпущенный централизованно на сервере CI.
основная идея в том, что Code, Config & DB Delta тесно связаны в любом случае. Код зависит от определенных свойств, заданных в конфигурации, и некоторых объектов (таблиц, представлений, ...) присутствие в БД. Так зачем делить это и тратить свое время? отслеживание все, чтобы убедиться, что он подходит вместе, когда вы можете просто отправить его вместе в первую очередь.
еще один большой аспект-это минимизация различий между средами, уменьшить причины отказа к абсолютному минимуму.
подробнее в my Непрерывная Доставка разговоры на переговорах:http://parleys.com/#id=2443&st=5