Как вы развертываете и управляете веб-приложением на C # для клиента с небольшими отличиями от вашего базового проекта?

Question

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

Edit: Прямо сейчас наше веб-приложение работает собственными силами, и мы создаем с помощью Cruise Control .NET и MSBuild с WDP. Что было бы хорошим вариантом для развертывания у заказчика? Мы не будем обновлять их сайт для них, поэтому желательно, чтобы их было легко развернуть и обновить.

Answer 1

Разветвите свой код.

Надеюсь, ваш код контролируется исходным кодом (если нет, начните сейчас!), Вам следует перейти от базы к ветви «Клиент Х» и просто внести небольшие косметические изменения в эту ветку. Затем просто создайте и разверните эту ветвь для этого клиента.

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

После просмотра комментариев: хорошо отметить, что конфигурация практична, но ТОЛЬКО если количество изменений незначительно, иначе вы будете загрязнять свой код логикой конфигурации. (Спасибо, комментаторы)

Итак: множество изменений -> Ветка (более удобная для сопровождения), несколько незначительных изменений -> Сделать настраиваемым (более практичным).

Answer 2

Мы должны делать это постоянно. Мы пытаемся обобщить и сделать различия между версиями настраиваемыми. Наиболее распространенные причины настройки:

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

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

Answer 3

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

Создание одноразовых s не масштабируется.

Answer 4

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