Комментарии 24
Для введения великолепно; ждем продолжения.
>> попытаюсь сделать этот вопрос более прозрачным, чем он есть (подозреваю для многих) сейчас
И многое, и многое ещё :)
>> попытаюсь сделать этот вопрос более прозрачным, чем он есть (подозреваю для многих) сейчас
И многое, и многое ещё :)
Интересно, ждём продолжения. :)
Будет еще интереснее, если в модели, которую Вы разработали, учитывается не только конфигурационный менеджмент исходного и бинарного кода, но и, например, базы данных, без которой бинарный код работать не будет.
Учитывается. Пусть не в полной мере, но планируется разработать не очень сложный инструмент для интеграции баз данных. Предполагается что он будет основан на использовании XML представления схемы базы данных, которую использует DBDesigner. Это, согласен, не enterprise уровень, но, тем не менее кое какое решение.
Отлично, но сразу хотелось бы отметить, что схема — это только половина проблемы. Зачастую поведение приложения определяется не столько схемой, сколько данными, если так можно выразиться, то управляющими данными.
Никто стандартные инсерты не отменял ;) А еще есть такие понятия как фикстуры, тоже могут в этом деле помочь. Фишка в тот, что всё хранится как исходный код
Уточню детали из реальной жизни:
1. Версии сборок. Централизовано назначается номер версии ( 4.28.2625 ) и добавляется во все, что связано с программой. ЭТО интегрируется в систему контроля версий и позволяет решать следующую задачу: «пользователи нашли баг в документации. Номер сборки 4.28.2625. Извлекаем и исправляем» или «у пользователя упала сборка 4.28.2625. Вот крашдамп. Извлекаем, собираем, смотрим»
2. Справка для программе. Часто с автоматической генерацией скриншотов из сборки. Хранится в виде некоего «исходника» в системе контроля версий, автоматически оттуда собирается в .chm, .pdf, .html и еще много чего и куда.
3. Установщик. Хорошо если программа детская и под windows — тогда это installshield или wix, исходники в репозитории, установщик собирается после того как собралось все остальное. Хуже когда программа взрослая — драйвера, сервисы, COM-DCOM-Вася-Пупкин-VB-ActiveX. Несколько сборок под разные операционные системы — тут и .pkg, и .dmg и чего только нету
4. Внутренняя документация :). Тоже живет в несчастной системе контроля версий. Кроме заголовка в .cpp вида "// тут все просто, 50kloc кода документировано на языке с++" часто содержит настройки генерации .doxygen, диаграмы, «vision» документы и прочую муть, свойственную сложным длительным проектам.
1. Версии сборок. Централизовано назначается номер версии ( 4.28.2625 ) и добавляется во все, что связано с программой. ЭТО интегрируется в систему контроля версий и позволяет решать следующую задачу: «пользователи нашли баг в документации. Номер сборки 4.28.2625. Извлекаем и исправляем» или «у пользователя упала сборка 4.28.2625. Вот крашдамп. Извлекаем, собираем, смотрим»
2. Справка для программе. Часто с автоматической генерацией скриншотов из сборки. Хранится в виде некоего «исходника» в системе контроля версий, автоматически оттуда собирается в .chm, .pdf, .html и еще много чего и куда.
3. Установщик. Хорошо если программа детская и под windows — тогда это installshield или wix, исходники в репозитории, установщик собирается после того как собралось все остальное. Хуже когда программа взрослая — драйвера, сервисы, COM-DCOM-Вася-Пупкин-VB-ActiveX. Несколько сборок под разные операционные системы — тут и .pkg, и .dmg и чего только нету
4. Внутренняя документация :). Тоже живет в несчастной системе контроля версий. Кроме заголовка в .cpp вида "// тут все просто, 50kloc кода документировано на языке с++" часто содержит настройки генерации .doxygen, диаграмы, «vision» документы и прочую муть, свойственную сложным длительным проектам.
вопрос: встречали ли вы унифицированный подход к менеджменту этого всего добра? возможно кто-то другой занимался этим до меня? почему-то у меня ощущение что от проекта к проекту это всё делается по-разному и причем настолько по-разному, что зачастую концов не сыщешь) это так или не совсем?
вроде как все вами описанные особенности в своем методе я попытался учесть. если интересно, следите за следующими статьями
вроде как все вами описанные особенности в своем методе я попытался учесть. если интересно, следите за следующими статьями
Встречал конечно. Этим занимаются либо Lead'ы, либо нанятые специалисты из компаний, которые на этом деньга зарабатывают. Свои процессы как правило никто не открывает, потому что это интеллектуальная собственность компаний где внедряется и за нее уплачена зряплата. Компании которые это продают за деньги тоже не открывают по понятным причинам :)
Тут есть один нюанс. ИМХО ( я могу ошибаться ) «унифицированный подход к менеджменту всего этого добра» нужен не сам по себе ( чтобы круто было ) а для решения конкретных задач. Когда я ЭТО делал, то фокусировался на решении списка задач — «реакция на крашдамп», «корректные скриншоты последней версии для всех 30 языков», «что отдавать локализаторам и что с них спрашивать», «как сделать и поддерживать версию с логотипом для журнала», «как переводить на новый язык», «а как на него переводить инсталятор?» и прочее. Список довольно большой :). Исходя из этого «списка неприятностей» составлялись методики автоматизации, скриптования и централизации. Дабы задачи решались в адекватные сроки и с прогнозируемым качеством.
В целом, могу сказать на собственно опыте что это долго, дорого и требует очень широкого кругозора и опыта общения с полным циклом разработки ПО. Включая нюансы продаж, техподдержки, марцетинга и прочего. ИМХО актуально для достаточно дорогих и хороших продуктов которые будут продаваться еще очень долго.
Тут есть один нюанс. ИМХО ( я могу ошибаться ) «унифицированный подход к менеджменту всего этого добра» нужен не сам по себе ( чтобы круто было ) а для решения конкретных задач. Когда я ЭТО делал, то фокусировался на решении списка задач — «реакция на крашдамп», «корректные скриншоты последней версии для всех 30 языков», «что отдавать локализаторам и что с них спрашивать», «как сделать и поддерживать версию с логотипом для журнала», «как переводить на новый язык», «а как на него переводить инсталятор?» и прочее. Список довольно большой :). Исходя из этого «списка неприятностей» составлялись методики автоматизации, скриптования и централизации. Дабы задачи решались в адекватные сроки и с прогнозируемым качеством.
В целом, могу сказать на собственно опыте что это долго, дорого и требует очень широкого кругозора и опыта общения с полным циклом разработки ПО. Включая нюансы продаж, техподдержки, марцетинга и прочего. ИМХО актуально для достаточно дорогих и хороших продуктов которые будут продаваться еще очень долго.
Ну я ориентировался в основном на веб-приложения, которые мы разрабатываем/разрабатывали. Попытался как-то обобщить приобретенный опыт. Плюс брал во внимание стандартный набор деятельности, который я уже перечислял: контроль версий, сборки, юнит-тесты, статический анализ кода, генерация документации на основе исходного кода и непрерывная интеграция. По-моему, включение всего этого в область интересов метода конфигурационного менеджмента должно покрыть задачи, возникающие у довольно большого пласта типовых проектов. Предполагаю также что на твердом фундаменте формализованного метода можно построить и более сложный процесс, который учитывает больше нюансов.
можно но не нужно… работал с конторой где «на твердом фундаменте формализованного метода» было построенно ФСЕ, на курилках только и разговоров было про этот «фундамент», использовалась в основном нецензурная лексика… но зато «со стороны руководства» все выглядело отлично — пипл шуршит, «вот я вижу что процесс идет» и все в таком духе… конторы больше нет… во многом благодаря фундаменту, очень многие ушли с причиной да я за эти-же деньги «там» не буду иметь этого гемороя… я конечно о приземленном а вы о вечном :)
что, там прям куча метрик собиралась и диаграммы строились?) круто! это ж долгожданная сингулярность (то есть рай) менеджера
вроде того, я тебе больше скажу, например, собирался вижн клиенту на основе экспертных оценок консультантов и коэфициентов подсмотренных разработчиком видимо в умной книге по менеджменту — жесть, иногда «почему-то» вижн получался «неправильным» поэтому «самому главному эксперту» приходилось его всегда перепроверять — редкий идиотизм, там много заморочек было.
лично я не встречал, думаю поиск серебряной пули находится где-то рядом — имхо менеджмент проекта доводить до фанатизЬма не стоит, есть мнение что затраты на менеджмент обратно-пропорциональны скилам его участников, и чрезмерное зацикливание на менеджменте должно стать тревожным звоночком о низких этих самых скилах…
ну в моем случае, как мне кажется, дела обстоят немного по-другому. есть набор деятельностей, которыми занимаются прогеры по ходу разработки. скилы по каждой из деятельностей вполне адекватны. но за счет того, что эти деятельности обычно проводились по отдельности, при их совместном использовании возникает куча проблем, так как они не приспособлены друг к другу. да и «менеджмент» и «конфигурационный менеджмент» — это довольно разные вещи. экстраполирование немного неуместно, хотя признаю — есть кое какие общие черты и недостатки.
У PMI есть стандарт Practice Standart for Project Configuration Management. У меня не дошли руки его прочитать, но думаю что 61 страница руководства должна быть очень подробной :)
Стандарт для членов PMI можно скачать у них на сайте pmi.org, либо отдельно купить там же
Стандарт для членов PMI можно скачать у них на сайте pmi.org, либо отдельно купить там же
Когда будет продолжение?
А как по вашему, насколько актуальна затронутая тема? Тут люди возражают по поводу того, что дескать «нафик нам эти формализованные процессы?» :)
я считаю тему актуальной. организация разработки порой бывает важней самой разработки.
Пока что не могу сказать конкретно, когда напишутся новые статьи. Дело в том, что не так просто уместить идеи из дипломной работы в нескольких статьях. К тому же еще не до конца продумана структура и формат будущего материала. Но желание поделиться наработками с сообществом довольно велико и это основной движимый фактор. Пока могу сказать одно — нужно чуть подождать. Спасибо вам за интерес.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Конфигурационный менеджмент (часть1, вступительная)