Настройка модели сборки / развертывания SVN для экземпляров Sage SalesLogix Web Dev/UAT/Prod
Я пытаюсь настроить архитектуру управления исходным кодом своей организации для нашего веб-приложения Sage SalesLogix. Мы используем SVN.
У нас есть 3 сервера, один разработчик, два для пользовательского приемочного тестирования и два для производства. Каждая среда имеет свою собственную базу данных.
Мы хотели бы сохранить транки в порядке, но это может быть затруднительно при управлении VFS так, как этого хочет SalesLogix.
Я хотел бы сделать следующее: - Пусть все разработчики используют установочный экземпляр DEV SalesLogix в App Arch. - Развертывание изменений на локальных машинах для локального модульного тестирования и проверки. - Когда все работы по разработке завершены, создайте пакет всех изменений в предлагаемой ревизии. - Один менеджер сборки устанавливает пакет на экземпляр установки UAT. - Компилировать и развертывать в папках UAT. - При отклонении удалить пакет и переустановить после изменений. - При принятии сделайте то же самое для производственных серверов и внесите изменения.
Хотя это означает, что у нас есть 3 VFS, это означает, что мы развиваемся только в одном, что, на мой взгляд, путь.
Я на правильном пути в своем мышлении?
1 ответ
Если честно, я не использовал SVN для модели SalesLogix, вместо этого я использую Git исключительно с SalesLogix. Это потому, что способ работы Git лучше согласуется с тем, как работает SalesLogix и Application Architect. В обычных случаях SCM не имеет значения, но он имеет значение с SalesLogix. Нельзя сказать, что SVN не будет хорошо работать с моделью SalesLogix, я знаю, что некоторые используют SVN с SLX (это будет не так просто, как с Git или Mercurial), но, честно говоря, за исключением предпочтений, SalesLogix VFS/ модель действительно хорошо работает только с полностью распределенным SCM.
Тем не менее, вы описываете, как я работаю с SalesLogix в Git. Я работаю, создаю ветку разработчика и делаю всю свою работу там. Мастер в основном отражает то, что находится в производстве, поэтому я могу в любое время перевести его в производство из мастера в случае необходимости. В ветке dev я делаю всю разработку, а также создаю ветки функций для определенных функций. Затем объедините обратно, когда функция завершена. Работая таким образом, вы сможете разработать и протестировать все, прежде чем перевести его в рабочую рабочую ветку. Как только он будет готов к развертыванию, я могу легко переключиться на производственную ветвь и затем развернуть ее оттуда. Если QA отвергает все, это просто вопрос возврата к производственной ветви или отката коммитов, если это необходимо. Кроме того, работая таким образом, вам действительно нужен только один VFS или модель. Не три отдельных, как вы описываете, поскольку все живет в отдельных ветвях и объединяется с основной ветвью только после того, как она полностью разработана и протестирована.
При этом, однако, я по-прежнему поддерживаю отдельные системы разработки и тестирования от производства (в основном, поскольку я работаю как бизнес-партнер SLX, а не как клиент SLX), в противном случае у вас нет возможности тестировать пакеты для доставки. В системе разработки я использую ветвление, описанное выше, чтобы позволить мне выпускать исправления в производство, пока продолжается разработка новых функций.
Хотелось бы, чтобы у меня была более конкретная информация о SVN, но концепции одинаковы, независимо от используемого SCM.