Параллельно разрабатываются несколько приложений, которые работают с базой данных и друг с другом. Каждое приложение разрабатывается независимо. Требуется — вести учет совместимых версий данных приложений, т.е. какая версия какого приложения совместима с какой версией другого приложения и т.д.
Сейчас это реализовано с помощью экселевской матрицы, но так как количество приложений и версий начинает расти, нужно что-то более продвинутое.
Пока напрашивается только одно — написать подобную систему самим, но сначала хочется узнать, что есть уже готового.
Вопрос — использует ли кто-то уже готовые системы для решения подобных задач, если да, то какие?
Желательно, чтобы это было полностью готовое решение.
Здравствуйте, Bug_z, Вы писали:
B_>Параллельно разрабатываются несколько приложений, которые работают с базой данных и друг с другом. Каждое приложение разрабатывается независимо. Требуется — вести учет совместимых версий данных приложений, т.е. какая версия какого приложения совместима с какой версией другого приложения и т.д.
Для начала — пара основных вопросов:
1. Если приложения разрабатываются независимо (т.е. в моем понимании, имея разную кодовую базу), то что означает "совместимость друг с другом"? Только по данным и структуре БД? Или ещё по другим интерфейсам — COM и т.п.?
2. Отслеживается ли как-то версионность структуры самой БД?
B_>Пока напрашивается только
... B_>Желательно, чтобы это было полностью готовое решение.
На эти вопросы можно ответить только ответив на мои Не факт, что потребуется отдельная софтина и даже сложная эксель-таблица.
При грамотной постановке СМа на проекте (например, выделении и отслеживании версий/бэйзлайнов приложений, БД) можно восстановить картину зависимостей только имея релизноты даже одной из программ всего комплекса. Хотя без деталей навскидку не скажешь.
В общем, ты пиши подробности, очень интересная задачка получается
Здравствуйте, Bug_z, Вы писали:
B_>Добрый день,
B_>Параллельно разрабатываются несколько приложений, которые работают с базой данных и друг с другом. Каждое приложение разрабатывается независимо. Требуется — вести учет совместимых версий данных приложений, т.е. какая версия какого приложения совместима с какой версией другого приложения и т.д.
предложу свою систему, которая была оразработана для отслеживания зависимостей в библиотеке библиотек/приложений
каждая бибилиотека имеет номер версии x.y.z. x увеличивается, когда в библиотеку вносится backward-incompatible изменение (скажем, переименовываем метод). y изменяется при расширении функционала с сохранением обратной совместимости. z — изменение реализации и правка ошибок
далее, если библиотека/приложение APP зависит от библиотеки LIB, то мы прописываем в зависимостях не только название библиотеки, но и номер версии. т.е. APP версии 1.3.1 требует LIB версии >=5.3.7 и <6
система компиляции по этим указаниям извлекает самую свежую версию LIB соответсвующую данным ограничениям
понятно, что при ихмегнении/добавлении нового функционала нужно заводить unstable ветки, в которые идёт накопление изменений и после стабилизации ещё раз изменять номер версии. как это делается в линуксе — чётные числа — stable версии, нечётные — unstable
Здравствуйте, Aquary, Вы писали:
B_>>Параллельно разрабатываются несколько приложений, которые работают с базой данных и друг с другом. Каждое приложение разрабатывается независимо. Требуется — вести учет совместимых версий данных приложений, т.е. какая версия какого приложения совместима с какой версией другого приложения и т.д.
A>Для начала — пара основных вопросов: A>1. Если приложения разрабатываются независимо (т.е. в моем понимании, имея разную кодовую базу), то что означает "совместимость друг с другом"? Только по данным и структуре БД? Или ещё по другим интерфейсам — COM и т.п.? A>2. Отслеживается ли как-то версионность структуры самой БД?
1. Все верно, приложения разрабатываются независимо и имеют разную кодовую базу (.NET WinForms, ASP.NET WebServices, C++/MFC). Совместимость отслеживается по нескольким направлениям:
1. По структуре БД.
2. По интерфейсам веб сервисов.
3. По данным на диске (при установке любого приложения на диске создается определенная файловая струкутра общая для совместимых приложений).
4. По структуре данных (через веб сервисы и файловую систему приложения обмениваются XML файлами)
Но в итоге мы имеет просто Эксел файл, где прописаны версии совместимых приложений.
2. Версия БД отслеживается, при изменении структуры БД — меняется версия.
Еще одно замечание — все эти приложения находятся на разных компьютерах в LAN, иногда даже в WAN, а не на одной машине.
A>На эти вопросы можно ответить только ответив на мои Не факт, что потребуется отдельная софтина и даже сложная эксель-таблица. A>При грамотной постановке СМа на проекте (например, выделении и отслеживании версий/бэйзлайнов приложений, БД) можно восстановить картину зависимостей только имея релизноты даже одной из программ всего комплекса. Хотя без деталей навскидку не скажешь.
Преследуется две основные цели:
1. Иметь всегда всю эту информацию о "совместимости" под рукой и быстро получать доступ к ней (сейчас это Эксел файл) т.е. своего рода inhouse solution. Создать БД (тут и возникает вопрос о уже готовом решении) и вносить всю информацию о совместимости между приложениями.
Например, если у клиента установлен определенный набор приложений и нужно ему обновить/установить новую версию приложения — будет ли она совместима с остальными уже работающими или нет. Эту информацию нужно получать непосредственно до инсталяции.
2. Проверять все эти совместимости в рантайме, т.е. непосредственно в рабочих условиях (тут я подозреваю, что придется все делать самим). Пока не совсем ясно, будут ли это проверки каждого отдельного приложения или всей системы в целом.
Просто странно, что для задачи номер один я не нашел ни одного готового решения в инете.
Здравствуйте, BulatZiganshin, Вы писали:
B_>>Параллельно разрабатываются несколько приложений, которые работают с базой данных и друг с другом. Каждое приложение разрабатывается независимо. Требуется — вести учет совместимых версий данных приложений, т.е. какая версия какого приложения совместима с какой версией другого приложения и т.д.
BZ>предложу свою систему, которая была оразработана для отслеживания зависимостей в библиотеке библиотек/приложений
BZ>каждая бибилиотека имеет номер версии x.y.z. x увеличивается, когда в библиотеку вносится backward-incompatible изменение (скажем, переименовываем метод). y изменяется при расширении функционала с сохранением обратной совместимости. z — изменение реализации и правка ошибок
BZ>далее, если библиотека/приложение APP зависит от библиотеки LIB, то мы прописываем в зависимостях не только название библиотеки, но и номер версии. т.е. APP версии 1.3.1 требует LIB версии >=5.3.7 и <6
BZ>система компиляции по этим указаниям извлекает самую свежую версию LIB соответсвующую данным ограничениям
BZ>понятно, что при ихмегнении/добавлении нового функционала нужно заводить unstable ветки, в которые идёт накопление изменений и после стабилизации ещё раз изменять номер версии. как это делается в линуксе — чётные числа — stable версии, нечётные — unstable
Спасибо за ответ.
Тут я вижу решение, как делать правильные сборки с правильными референсами автоматически, но вопрос в другом, где хранилась у вас вся эта информация о том какая версия LIB (библиотеки) требуется APP (приложению). Т.е. у меня есть АРР 1.4.5 — какая версия LIB мне нужна?
В данной ситуации у меня как раз проблема, как быстро получить эту информацию, при чем не всегда это будут программисты. В данный момент мы решаем эту проблему с помощью Эксел файла.
В ответе Aquary я более подробно описал условия и проблему.
Здравствуйте, Bug_z, Вы писали:
B_>Добрый день,
B_>Параллельно разрабатываются несколько приложений, которые работают с базой данных и друг с другом. Каждое приложение разрабатывается независимо. Требуется — вести учет совместимых версий данных приложений, т.е. какая версия какого приложения совместима с какой версией другого приложения и т.д. B_>Сейчас это реализовано с помощью экселевской матрицы, но так как количество приложений и версий начинает расти, нужно что-то более продвинутое.
B_>Пока напрашивается только одно — написать подобную систему самим, но сначала хочется узнать, что есть уже готового.
B_>Вопрос — использует ли кто-то уже готовые системы для решения подобных задач, если да, то какие? B_>Желательно, чтобы это было полностью готовое решение.
B_>С уважением, Юрий.
Такой вопрос — исходники приложений хранятся централизованно на одном сервере, т.е. под одним source control — сервером? Если да, то одно из возможных решений — использовать хорошую SCM систему. Из всех мне известных замечательно с такой задачей справляется ClearCase. В нем можно ввести зависимости между компонентами. Причем можно делать так, что в одну сборку не попадут компоненты, конфликтующие по зависимостям. Если интересно, могу рассказать подробнее.
С чужих слов знаю, что такую функциональность предоставляет Maven, но это только для Java.
Здравствуйте, Bug_z, Вы писали:
B_>Добрый день,
B_>Параллельно разрабатываются несколько приложений, которые работают с базой данных и друг с другом. Каждое приложение разрабатывается независимо. Требуется — вести учет совместимых версий данных приложений, т.е. какая версия какого приложения совместима с какой версией другого приложения и т.д. B_>Сейчас это реализовано с помощью экселевской матрицы, но так как количество приложений и версий начинает расти, нужно что-то более продвинутое.
B_>Пока напрашивается только одно — написать подобную систему самим, но сначала хочется узнать, что есть уже готового.
B_>Вопрос — использует ли кто-то уже готовые системы для решения подобных задач, если да, то какие? B_>Желательно, чтобы это было полностью готовое решение.
ИМХО проблема на 100% организационная.
Я бы ее решал а ля жавовские JSR — то есть онисание куска функционала (контракта).
получится простая табличка
JSR88 — прога1 >= v.2.2 прога 2 >= v6.8 etc
JSRXXX и так далее
в real life у вас больше пары тройки кусков (а ля JSR) получится не должно.
иначе compatibility hell обеспечен.
Или уж другая альтернатива. Долго трахаемся и определяем рабочие комбинации и их в табличку
Здравствуйте, Bug_z, Вы писали:
B_>Вопрос — использует ли кто-то уже готовые системы для решения подобных задач, если да, то какие? B_>Желательно, чтобы это было полностью готовое решение.
Тут, ИМХО, проще использовать организационные меры.
Самое простое — координированые номера (внутрених) версий библиотек. То есть, каждая библиотека получает внутреннюю версию x.y.z.k, причем гарантируете, что ВСЕ проекты внутри ветки x.y должны работать между собой.
Мы еще такую нотацию использовали — все "работающие" проекты имели четную версию "y", а временные сломаные и несовместимые ни с чем версии — нечетную.
Начну с конца 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
в итоге устанавливеются 1 большая зависимость
client_01.01.01, server_group_02.01.02 -> core_group_03.01.04
That's it при обновлении софта у заказчика разворачиваются не много мелких приложений, а 3 группы — не больше, но и не меньше. Причем зависимость между группами — однозначная.
Как только обновляется версия одного из приложений — обновляется и версия его группы. А имя малькое описание — кто от кого зависит — легко узнать кто ещё зависимый должен обновиться, а кого можно не трогать.
Очень важн вести release notes как каждого приложения, так и групп. Каждый выпуск релиза сопровождается релизнотами, где прописывается — от чего оно зависит.
По большому счету, таким методом можно перейти от большого количества конкретных аппликух — к абстрактным модулям.
Кстати, этот же метод позволит упростить процесс выпуска релизов и их тестирование — сначала будут выпускать приложение, тестироваться само по себе, потом внутри модуля, затем — тестирование межгрупповое.
Последний шаг (по желанию) — объединение всего в одну группу типа "мега-сборник". Что это дает — можно выпускать промежуточные версии аппликух, групп, тестировать их как угодно — а затем периодически выставлять заказчику сборник целиком, т.е. полностью заменяя весь софт на более новый. В перерывах между подобными выпусками делать периодические апдейты отдельных групп по необходимости, с оглядкой на общую межгрупповую совместимость.
Таким образом спец софт просто будет не нужен — все необходимые данные будут смотреться в релизнотах групп или всего мега-сборника. Более мелкие зависимости и частные случаи — смотреться в релизнотах мелких приложений.
Если же существует несколько заказчиков и для каждого есть где-то свои версии каждой из программ, где-то общая часть, единая для всех... Ну тогда 2 варианта:
1. продолжать эту идею дальше и производить группировку по другим критериям
2. менять место работы
Здравствуйте, Shota, Вы писали:
B_>>Параллельно разрабатываются несколько приложений, которые работают с базой данных и друг с другом. Каждое приложение разрабатывается независимо. Требуется — вести учет совместимых версий данных приложений, т.е. какая версия какого приложения совместима с какой версией другого приложения и т.д. B_>>Сейчас это реализовано с помощью экселевской матрицы, но так как количество приложений и версий начинает расти, нужно что-то более продвинутое.
S>Такой вопрос — исходники приложений хранятся централизованно на одном сервере, т.е. под одним source control — сервером? Если да, то одно из возможных решений — использовать хорошую SCM систему. Из всех мне известных замечательно с такой задачей справляется ClearCase. В нем можно ввести зависимости между компонентами. Причем можно делать так, что в одну сборку не попадут компоненты, конфликтующие по зависимостям. Если интересно, могу рассказать подробнее. S>С чужих слов знаю, что такую функциональность предоставляет Maven, но это только для Java.
Все исходники хранятся под TFS (Team foundation server) на одном сервере, но в разных TeamProjects (специфика TFS).
Вообще-то интересно узнать как это делает ClearCase и как там можно все это настроить. Особенно интересно узнать, как можно эти зависимости просматривать, можно ли делать queries по этим зависимостям и имея версии одних приложений, получать все зависимые.
Здравствуйте, Aquary, Вы писали:
A>Начну с конца B_>>Просто странно, что для задачи номер один я не нашел ни одного готового решения в инете. A>Потому что из все массы производимого ПО доля программных комплексов (когда несколько независимых аппликух работают вместе) — очень мал. И чем больше приложений в комплексе, тем мЕньший процент их "встречаемости". Соответсвенно, насколько велика вероятность встретить подобный спец. софт, написанный для ещё более "спец." софта? Эк завернул...
Вероятность стремится к нулю, за пару дней поиска в интернете ни одного рельного ПО для подобной проблемы
B_>>1. Все верно, приложения разрабатываются независимо и имеют разную кодовую базу (.NET WinForms, ASP.NET WebServices, C++/MFC). Совместимость отслеживается по нескольким направлениям:
B_>> B_>>1. По структуре БД. B_>>2. По интерфейсам веб сервисов. B_>>3. По данным на диске (при установке любого приложения на диске создается определенная файловая струкутра общая для совместимых приложений). B_>>4. По структуре данных (через веб сервисы и файловую систему приложения обмениваются XML файлами) B_>>
A>2. изменить организацию выпуска релизов софта, т.е. его версий.
A>That's it при обновлении софта у заказчика разворачиваются не много мелких приложений, а 3 группы — не больше, но и не меньше. Причем зависимость между группами — однозначная. A>Как только обновляется версия одного из приложений — обновляется и версия его группы. А имя малькое описание — кто от кого зависит — легко узнать кто ещё зависимый должен обновиться, а кого можно не трогать.
A>Очень важн вести release notes как каждого приложения, так и групп. Каждый выпуск релиза сопровождается релизнотами, где прописывается — от чего оно зависит.
A>По большому счету, таким методом можно перейти от большого количества конкретных аппликух — к абстрактным модулям.
A>Кстати, этот же метод позволит упростить процесс выпуска релизов и их тестирование — сначала будут выпускать приложение, тестироваться само по себе, потом внутри модуля, затем — тестирование межгрупповое.
Этот вариант сейчас и видится наиболее подходящим для решения проблемы, так как на самом деле все эти приложения группируются по определенным признакам, но пока это больше используется отделом маркетинга для продвижения продуктов , а не для SCM.
По результатам этой ветки (так же интересные идеи по именнованию версий), напишу финальный результат, как это мне представляется в конечном итоге.
Не факт, что потребуется отдельная софтина и даже сложная эксель-таблица.
