Как к Зависимостям от системы транспортировки?

Лучший источник информации обычно находится в Файлах конфигурации. Это обычно имеет строки подключения, URL веб-сервиса и т.д., которые дадут хорошую идею о внешних зависимостях.

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

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

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

Это кажется, что Вы квалифицируете для использования свободного Общественного Выпуска Основы, которую можно использовать максимум на 30 серверах - всего загрузка это и проверить его. Затем сообщите нам то, что Вы думаете!

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

Выключите каждую машину один за другим и посмотрите что повреждения..; p

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

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

Это - хороший вопрос - мы боремся с этим каждым разом, когда это кажется.

, Что мы попытались сделать за прошлый год или так быть "безжалостными" на двух вещах:

1. автоматизация - если Вы автоматизируете его и создаете/развертываете часто, затем процесс автоматизации будет иметь тенденцию получать вещи право большинство времен (настройки конфигурации, и т.д.)

2. Wiki, Wiki, Wiki - мы пытаемся быть хардкором при хранении команды и актуальной Wiki проекта.

Любопытный видеть другие ответы.

Походит на задание для исследования предприятия, которое автоматизировано насколько оно может пойти. В зависимости от размера Вашей организации и среды там различные решения. Для больших сред Вам будет нужен CMDB (База данных управления конфигурацией) так или иначе. Продукты как HP Universal CMDB могут обнаружить и отследить зависимости в крупномасштабных средах.

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

, Таким образом, ответ зависит от того, что Вы рассматриваете как 'многих'.

Сопоставление системных зависимостей - это одно. Истинные настройки среды, идентификаторы uid, пароли, настройки олицетворения, имена баз данных и другие данные, которые меняются от разработки к qa и uat к производству, являются настоящей проблемой.

Кто хранит / запоминает их все?

Разработчик не знает, какие производственный сервер (ы), на котором будет размещаться его приложение. Он только документирует имя своей базы данных разработки, uid, pwd и описывает таблицы своей базы данных, строки conn и т. Д.

После того, как он зарегистрирован в репозитории кода и мигрировал в среду QA, который является хранителем необходимых данных чтобы обновить этот файл конфигурации с правильными значениями?

Опять же, при миграции на QA и UAT, кто?

Кто несет ответственность за информирование следующей группы миграции о том, что необходимо изменить?

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

Помимо ответственности, я думаю, это центральное хранилище этой информации.

т.е. Система, которая хранит все параметры конфигурации для всех проектов / приложений, и в зависимости от вашей «роли» вы можете / не можете видеть фактические значения.

Разработчик завершает сборку и создает запрос на перенос в «системе» . Специалист по контролю качества получает уведомление о том, что сборка ### готова. Специалист по контролю качества входит в «систему» ​​и получает инструкции по миграции. Теперь они четко знают, что нужно сделать, и начинают процесс проверки кода и миграции.

Повторите для UAT и, в конечном итоге, для производства.

Когда кто-то создаст эту систему миграции, дайте мне знать, потому что ЭТО поможет многим люди.

Может, я сам построю ... Кто хочет меня нанять?