Я бы посоветовал рассматривать это не как усилия по разработке программного обеспечения (Spring или иным образом), а скорее как усилие по управлению конфигурацией.
То, что мы делаем для достижения большинства из этих требований, - это различение конфигурации, которая остается неизменной в разных средахиз конфига, который потенциально может варьироваться.Например, большая часть проводки вашего приложения будет оставаться постоянной, тогда как пароли, URL-адреса веб-служб и т. Д. Будут отличаться.(Обратите внимание, что иногда проводка приложения тоже будет меняться. Например, возможно, на вашем локальном устройстве разработчика вы используете локальную аутентификацию, но в других средах вы используете CAS.)
Затем убедитесь, что постоянная конфигурация является лишь частью приложения.сам по себе (т.е. упакован в WAR или EAR), а изменяемый конфиг является внешним.
Где его экстернализировать?Настройте репозиторий контроля версий (config repo) с помощью своего любимого инструмента контроля версий, а затем создайте папки для различных сред.Поместите конфигурацию, специфичную для среды, в соответствующую папку, а затем настройте свои сценарии развертывания так, чтобы исходный файл конфигурации находился в правильной папке.
Эта схема довольно приятна.Вы получаете централизованное управление конфигурацией, которая помогает контролировать дрейф, а также обеспечивает возможность аудита, откат, поддержку диагностики и т. Д. Разветвите конфигурацию так же, как вы делали бы исходный код.
В частности, в отношении Spring 3.1 будет включатьподдержка того, что называется профилями, что, я думаю, позволяет адаптировать конфигурацию к конкретной среде.Я еще не смотрел на это, но это то, что я помню, слышал в SpringOne 2GX.