Как вы поддерживаете отдельные веб-сервисы для dev / stage / production

Question

Мы хотим сохранить 3 веб-сервиса для разных этапов развертывания, но как нам определить в нашем приложении, какой сервис использовать? Мы просто поддерживаем 3 веб-ссылки и как-то их используем?

Answer 1

Не поддерживать различия в коде, а скорее через файл конфигурации. Таким образом, все они выполняют один и тот же код, но с разными значениями конфигурации (т. Е. Порт, к которому привязывается, имя хоста, на которое нужно ответить, и т. Д.)

Answer 2

Как уже упоминали другие, вы захотите сохранить эту информацию в файле конфигурации. На самом деле, я бы предложил использовать разные конфигурационные файлы для каждой среды. Это решит неизбежную проблему наличия нескольких настроек для каждой среды, например, у вас могут быть отдельные параметры для URL-адреса веб-службы и порта веб-службы или дополнительные параметры для работы с https / security.

Все сказанное, убедитесь, что вы решаете следующие потенциальные проблемы:

Если веб-служба делает что-то особенно важное для приложения, вы можете объединить приложение с веб-службами в каждой среде (т. Е. Иметь версию своего приложения в каждой среде). Конечно, любые изменения в интерфейсе проще, когда вы делаете это таким образом.

Убедитесь, что кому-то очевидно, с какой версией веб-службы вы общаетесь.

Answer 3

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

Answer 4

Когда я последний раз работал над проектом с веб-сервером, мы решали эту проблему следующим образом:

• msbuild /t:deploy будет собирать и развертывать в тестовой среде, которая была частично разделена командой, а частично - разработчиком. Значение по умолчанию для $(SERVER) было $(USERNAME).
• msbuild /t:deploy /p:server=test будет развернут в общей тестовой среде, на которую могут смотреть не разработчики.
• msbuild /t:deploy /p:server=live развернется на работающем сервере. Я думаю, что добавил дополнительное рукопожатие, как ошибка, если у вас не было /p:secret=foo, просто чтобы убедиться, что вы не сделали это случайно.

Answer 5

К вашему сведению, это было рассмотрено здесь вчера:

Как вы поддерживаете Java-приложения в различных промежуточных средах?

Answer 6

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

Answer 7

Вместо использования веб-ссылок создайте прокси-классы из WSDL веб-службы, используя wsdl.exe . Сгенерированные классы будут иметь свойство Url, которое можно установить в зависимости от этапа развертывания (dev, qa, production и т.

Answer 8

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

Использование конфигурации, а не кода для переключения между dev, stage и production очень ценно для тестирования. При развертывании в рабочей среде вы хотите убедиться, что развертываете тот же самый код, который был протестирован, а не что-то немного другое. Все, что вам нужно переключить между dev и production, это конфиг.