Здравствуйте, Bug_z, Вы писали:

Начну с конца
B_>Просто странно, что для задачи номер один я не нашел ни одного готового решения в инете.
Потому что из все массы производимого ПО доля программных комплексов (когда несколько независимых аппликух работают вместе) — очень мал. И чем больше приложений в комплексе, тем мЕньший процент их "встречаемости". Соответсвенно, насколько велика вероятность встретить подобный спец. софт, написанный для ещё более "спец." софта? Эк завернул...

B_>1. Все верно, приложения разрабатываются независимо и имеют разную кодовую базу (.NET WinForms, ASP.NET WebServices, C++/MFC). Совместимость отслеживается по нескольким направлениям:

B_>

B_>1. По структуре БД.
B_>2. По интерфейсам веб сервисов.
B_>3. По данным на диске (при установке любого приложения на диске создается определенная файловая струкутра общая для совместимых приложений).
B_>4. По структуре данных (через веб сервисы и файловую систему приложения обмениваются XML файлами)
B_>

B_>Еще одно замечание — все эти приложения находятся на разных компьютерах в LAN, иногда даже в WAN, а не на одной машине.

Могу быть неправ, но со стороны это выглядит как нарастающий бардак Почему — потому что всё катится к уже упомянутому compatibility hell. Решений по большому счету 2:
1. переделывать архитектуру, приводить все компоненты к единому знаменатели — половина проблем с синхронизации по версим исчезнут сами, вторая половина будет более просто контролироваться.
2. изменить организацию выпуска релизов софта, т.е. его версий.

Первый вариант рассматривать не буду — как правило, он неосуществим при наличии большой кодовой базы.

Остановлюсь на втором варианте.
Вместо того, чтобы отслеживать много отдельных "мелких" версий, стОит объединять программы, подсистемы, а то и всю систему в целом в бОльшие блоки и давать им свои версии-метки. Имея фактически 2-3 "объединенные" метки, их между собой проще сращивать, чем 20-30 маленьких.
Например, есть такие подсистема/программы/сервисы, имеющие свои метки АКА версии
service_01.02.1A
db_structure_01.05.05
app_client_03.01.02
app_server_02.2B.01
web_site_01.01.06
small_app_01.01.01
foo_bar_03.01.02

между ними существует много кросс-зависимостей, например,
web_site_01.01.06, small_app_01.01.01 зависят от db_structure_01.05.05
service_01.02.1A, app_server_02.2B.01 -> foo_bar_03.01.02
app_client_03.01.02 -> db_structure_01.05.05
при этом foo_bar_03.01.02 -> db_structure_01.05.05

Группируем приложения
web_site_01.01.06, small_app_01.01.01, app_client_03.01.02 == client_01.01.01
service_01.02.1A, app_server_02.2B.01 == server_group_02.01.02
foo_bar_03.01.02, db_structure_01.05.05 == core_group_03.01.04

в итоге устанавливеются 1 большая зависимость
client_01.01.01, server_group_02.01.02 -> core_group_03.01.04

That's it при обновлении софта у заказчика разворачиваются не много мелких приложений, а 3 группы — не больше, но и не меньше. Причем зависимость между группами — однозначная.
Как только обновляется версия одного из приложений — обновляется и версия его группы. А имя малькое описание — кто от кого зависит — легко узнать кто ещё зависимый должен обновиться, а кого можно не трогать.

Очень важн вести release notes как каждого приложения, так и групп. Каждый выпуск релиза сопровождается релизнотами, где прописывается — от чего оно зависит.

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

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


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

Таким образом спец софт просто будет не нужен — все необходимые данные будут смотреться в релизнотах групп или всего мега-сборника. Более мелкие зависимости и частные случаи — смотреться в релизнотах мелких приложений.

Если же существует несколько заказчиков и для каждого есть где-то свои версии каждой из программ, где-то общая часть, единая для всех... Ну тогда 2 варианта:
1. продолжать эту идею дальше и производить группировку по другим критериям
2. менять место работы