Развертывание / управление веб-сайтами для нескольких клиентов

Question

У меня есть небольшой бизнес, который продает веб-решения для клиентов. Веб-сайты служат той же цели; разрешить клиенту отправлять и планировать SMS-сообщения.

Каждый сайт немного отличается. Например, 1 сайт имеет обязательную информацию, такую ​​как сведения об адресе и имя группы, в то время как другой сайт предъявляет другие требования, такие как регистрация IP-адреса пользователя, но не нуждается в каких-либо деталях адреса.

Все веб-сайты построены с использованием LINQ TO SQL и являются просто веб-сайтами, а не веб-приложениями.

Каждый сайт имеет свою базу данных на моем сервере.

Каждый веб-сайт использует exe для отправки сообщений. Этот exe-файл - это тот же exe-файл, но каждый веб-сайт имеет свою собственную процедуру копирования и планирования, расположенную в каталоге bin сайта, и запускается с помощью запланированных задач Windows.

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

Клиенты могут изменять страницы ASPX, но не код позади.

На данный момент у меня на компьютере разработчика есть файловая структура, которая читает что-то вроде:

Client1Dev Client1_Published

Client2Dev Client2_Published

... и так далее

Отдельно есть приложение опроса (консольное приложение Windows)

Когда я делаю изменения, я публикую сайт клиента в его каталоге _Published, а затем копирую DLL из каталога bin на рабочий сервер.

Мой вопрос на самом деле: что бы вы сделали, чтобы управлять этим материалом? Если Клиент 1 захочет внести изменения, я внесу изменения на сайт разработчика, скопирую на опубликованный и затем отправлю на FTP-сервер.

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

Если я нахожу ошибку, это настоящий кошмар, так как мне нужно обновить все сайты 1 на 1, чтобы исправление ошибки не нарушало конкретный проект.

Любой совет по этому поводу?

Answer 1

Исходный контроль, автоматизированные тесты. Короче, процесс.

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

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

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

Answer 2

Сложный, но один из способов минимизировать сложность может заключаться в том, чтобы в вашем хранилище исходного кода была только одна ветвь, а затем попытаться смешать принцип Open Closed , как указано в SOLID. Таким образом, должно быть возможным предоставлять изменения, запрошенные вашими клиентами, без разветвления вашего исходного дерева. Первая идея, которая возникла у меня в голове, была «использовать фабричный шаблон», но я научился трудному способу не бросать шаблоны после любой проблемы, которую я вижу, но все же ..

Answer 3

Взгляните на руководство по управлению исходными кодами Эрика Синка, а затем посмотрите на что-то вроде Cruise Control.net, чтобы улучшить процесс сборки. Большинство инструментов автоматической сборки могут быть настроены с помощью скриптов и т. Д. Для выполнения любых необходимых шагов перед тем, как выложить код.

Answer 4

Я работал с подобной установкой, и это кошмар, без легкого выхода.

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

Лично я думаю, что вам было бы лучше предоставить [гибкую CMS] [1] и дать каждому клиенту отдельную базу данных и тему. Это было бы большой работой, чтобы добраться туда, поэтому вы можете развернуть ее медленно, но в конечном итоге это будет намного проще. Поработав над собственным и открытым исходным кодом CMS, маршрут с открытым исходным кодом, кажется, имеет много преимуществ.

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

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