Настройка модели сборки / развертывания SVN для экземпляров Sage SalesLogix Web Dev / UAT / Prod

Question

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

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

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

Я хотел бы сделать следующее: - Пусть все разработчики используют установочный экземпляр DEV SalesLogix в App Arch.- Развертывание изменений на локальных машинах для локального модульного тестирования и проверки.- Когда все работы по разработке завершены, создайте связку всех изменений в предлагаемой ревизии.- Один менеджер сборки устанавливает пакет на экземпляр установки UAT.- Компилировать и развертывать в папках UAT.- При отклонении удалить пакет и переустановить после изменений.- При принятии сделайте то же самое для производственных серверов и внесите изменения.

Хотя это означает, что у нас есть 3 VFS, это означает, что мы развиваемся только в одной, что, на мой взгляд, является подходящим решением.1009 *

Я на правильном пути в своих мыслях?

Answer 1

Если честно, я не использовал SVN для модели SalesLogix, вместо этого я использую Git исключительно с SalesLogix.Это потому, что способ работы Git лучше согласуется с тем, как работает SalesLogix и Application Architect.В обычных случаях SCM не имеет значения, но имеет значение с SalesLogix.Нельзя сказать, что SVN не будет хорошо работать с моделью SalesLogix, я знаю, что некоторые используют SVN с SLX (это будет не так просто, как с Git или Mercurial), но, честно говоря, за исключением предпочтений, SalesLogixVFS / модель действительно хорошо работает только с полностью распределенным SCM.

Тем не менее, вы описываете, как я работаю с SalesLogix в Git.Я работаю, создаю ветку разработчика и делаю всю свою работу там.Мастер в основном отражает то, что находится в производстве, поэтому я могу в любое время перевести его в производство из мастера в случае необходимости.В ветке dev я делаю всю разработку, а также создаю ветки функций для определенных функций.Затем объедините обратно, когда функция завершена.Работая таким образом, вы сможете разработать и протестировать все, прежде чем перенести это в рабочую рабочую ветку.Когда он будет готов к развертыванию, я могу легко переключиться на производственную ветвь и затем развернуть ее оттуда.Если QA отвергает все, это просто вопрос возврата к производственной ветви или отката коммитов, если это необходимо.Кроме того, работая таким образом, вам действительно нужен только один VFS или модель.Не три отдельных, как вы описываете, поскольку все живет в отдельных ветвях и объединяется с основной ветвью только после того, как она полностью разработана и протестирована.

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

Хотелось бы, чтобы у меня была более конкретная информация о SVN, но концепции те женезависимо от используемого СКМ.