Comments 42
хорошая статья. спасибо. буду ждать с нетерпением продолжения.
Если кто что хочет увидеть в будущих стятьях — пишите. Если это уже написано или в планах — дам примерныфй срок, когда будет опубликовано. Если нет — будем обсуждать.
Если можно, в список ссылок можно добавить вот этот сборник по практическим руководствам: www.scmpatterns.com, а так же полезную ссылку www.infoq.com/articles/agile-version-control (там, правда, чуть глубже про version control, но подход к управлению конфигурациями тоже прослеживается).
Спасибо за ссылки, ознакомлюсь.
Вообще, про контроль версий будут отдельные заметки. Посмотрим заодно, чем agile принципиально отличается в этом плане от чего-то другого.
Насчет включения ссылок — только после ознакомления :)
Вообще, про контроль версий будут отдельные заметки. Посмотрим заодно, чем agile принципиально отличается в этом плане от чего-то другого.
Насчет включения ссылок — только после ознакомления :)
Прочитал статью, отлично и просто всё описано.
Конечно, «This paper is not primarily targeted for version control experts, in fact such experts probably won't find anything new here. This paper is aimed at the rest of us, those of us that just want to learn simple and useful ways to collaborate.»
Однако описаные практики почти универсальны для разных методологий. Нечто похожее я как раз сейчас описываю в разделе «Параллельная разработка», только с упором на компонентную разработку и продуктовые линейки. В общем, позаимствую оттуда идеи для пары картинок :) ибо сам я не художник :)
Конечно, «This paper is not primarily targeted for version control experts, in fact such experts probably won't find anything new here. This paper is aimed at the rest of us, those of us that just want to learn simple and useful ways to collaborate.»
Однако описаные практики почти универсальны для разных методологий. Нечто похожее я как раз сейчас описываю в разделе «Параллельная разработка», только с упором на компонентную разработку и продуктовые линейки. В общем, позаимствую оттуда идеи для пары картинок :) ибо сам я не художник :)
Будет просто замечательно, если сделаете акцент в сторону управления задачами (изменениями/запросами/требованиями). Насколько я знаю, контроль версий файлов, автосборки и багтрекинг достаточно хорошо освещены. А вот как делается правильная постановка задачи и запись ее результатов — мало где описано.
Будет отдельный топик про контроль изменений и отслеживание запросов на изменение рабочих продуктов. При этом рабочие продукты могут быть самыми разнообразными — от требований, кода и тестов до конечных бинарников и инсталяционных пакетов. Не важно, в каких именно продуктах отслеживаются изменения — важно делать это постоянно и под контролем.
Про идентификацию рабочих продуктов будет как раз следующий пост.
Про отслеживание запросов на изменения — чуть позже, через 1 или 2.
За интерес спасибо. :)
Про идентификацию рабочих продуктов будет как раз следующий пост.
Про отслеживание запросов на изменения — чуть позже, через 1 или 2.
За интерес спасибо. :)
> сертификата CMM/CMMI Level 2.
Нельзя ли подробнее об этом, что зачем, в каких случаях требуется?
Нельзя ли подробнее об этом, что зачем, в каких случаях требуется?
Для начала проще прочитать на Вике:
en.wikipedia.org/wiki/Capability_Maturity_Model
От себя — CMM/CMMI в основном нужен как некий сертификат на уровне организации, говорящий о её способности стандартизовать свои внутренние процессы и постоянно их улучшать.
Можно попробовать внедрить практики «для себя» — просто чтобы подтянуть качество выполняемых проектов.
Крупные компании, нанимающие подрядчиков, или требуют наличия подобного уровня или сами организуют внутрение аудиты, для оценки способностей организации.
Остальные же часто сертифицируются «для ветрины».
en.wikipedia.org/wiki/Capability_Maturity_Model
От себя — CMM/CMMI в основном нужен как некий сертификат на уровне организации, говорящий о её способности стандартизовать свои внутренние процессы и постоянно их улучшать.
Можно попробовать внедрить практики «для себя» — просто чтобы подтянуть качество выполняемых проектов.
Крупные компании, нанимающие подрядчиков, или требуют наличия подобного уровня или сами организуют внутрение аудиты, для оценки способностей организации.
Остальные же часто сертифицируются «для ветрины».
Т.е. внутренняя процедура, для улучшения управления процессом созданием софта?
В качестве требований к процессу организации производства (наподобие ISO9000) в процессе проведения тендеров, например, не выступает?
В качестве требований к процессу организации производства (наподобие ISO9000) в процессе проведения тендеров, например, не выступает?
В первую очередь — это всегда набор внутренних изменений и целый ряд документов, описывающих, как жить в новых условиях организации производства.
Внешняя сертификация — это оценка того, как коррелируют между собой 1. внутренняя организация работы 2. документы, описвающие это 3. стандарт, на основе которого сделаны 1 и 2.
СММ может быть существенным плюсом при участии в тендере.
Насчет одного из требований — встречал упоминание, что какие-то из госстуруктур США (как бы даже не минобороны, поправьте кто-нибудь, если не прав) практически не рассматривает учатников тендаров, у которых нет высокого (от 3) уровня СММ.
Внешняя сертификация — это оценка того, как коррелируют между собой 1. внутренняя организация работы 2. документы, описвающие это 3. стандарт, на основе которого сделаны 1 и 2.
СММ может быть существенным плюсом при участии в тендере.
Насчет одного из требований — встречал упоминание, что какие-то из госстуруктур США (как бы даже не минобороны, поправьте кто-нибудь, если не прав) практически не рассматривает учатников тендаров, у которых нет высокого (от 3) уровня СММ.
о ;) люблю хорошо приготовленный топик ;) все с толком и расстановкой ;) я бы удвоил материал для одного поста, читается очень легко ;)
Хороший пример хорошей статьи — с нетерпением жду продолжения
Пока особо комментировать по-моему нечего, но вступление очень интересное и грамотно, с толком написанное, что приятно.
Интересно какова ваша проектная роль при использовании этих средств, это могло повлиять на изложение.
Интересно какова ваша проектная роль при использовании этих средств, это могло повлиять на изложение.
На проектах для Моторолы я был СМ-инженером в широком смысле этого термина. Занимался как рутинной работой вроде мержа исходников и выпуска билдов, так и координацией работы СМ-команды. Также участвовал в подготовке компании к сертификации на СММ — видимо, оттуда ноги и растут.
Ко всему прочему, я уже 8 лет преподаю с нашем Политене второму курсу пары ИТ-специальностей — это тоже накладывает отпечаток на доходчивость изложения Ж-))
Ко всему прочему, я уже 8 лет преподаю с нашем Политене второму курсу пары ИТ-специальностей — это тоже накладывает отпечаток на доходчивость изложения Ж-))
Статья хорошая. Жду продолжения.
Итак, чтобы было понятно, с чего начинается СМ и что же это за рабочие продукты, подконтрольные СМу, предлагаю вниманию следующую часть:
Вы ещё отбеливаете, тогда мы идём к вам.
IBM Rational ClearCase — один из худших образцов SCM. И прежде чем его внедрять может стоить не читать очень красочные презентации, а попробовать попользоватся.
Всю идею распределённой разработки убили отстойнейшей реализацией с идиотским интерфейсом.
Управлять конфигурацией, говорите. Когда один человек должень убивать по три часа чтобы смерджить дневную разработку это убивает всю идею контроля версий, потому что люди перестают делать комиты.
А особенный кайф я получаю от попыток слить бинарные файлы. НЕТ у этой бл… ой системы возможности сказать я знаю что делаю возьми файл этой версии. Эта поделка криворуких програмистов чесно попытается смерджить 11 Мб файл FrameMaker-а, хотя итак известно что не должна, а потом расспишется в неспособности.
Чтобы влить бинарник нужны танцы с бубном вроде этих www.ibm.com/developerworks/rational/library/07/0424_hu/index.html
Удовольствие также получаю на Remote Client когда попытаюсь смерджить 4 Кб xml, это поделка может вычислять отличия 20-30 мин., это какими руками надо так код писать?
Я работал с многими людьми из разных компаний и никогда не слышал доброго слова о Rational ClearCase, исключение составляли только менеджеры и приближенные к ним люди которым не приходится сталкиватся с этим ужасом каждый день.
Такое впечатление что в Rational IBM нет ни одного юзабилиста, одно сборище технодаунов, потому чтобы создать метку нужно запустить один инструмент, а чтобы применить её к объекту запускаем второй.
IBM Rational ClearCase — один из худших образцов SCM. И прежде чем его внедрять может стоить не читать очень красочные презентации, а попробовать попользоватся.
Всю идею распределённой разработки убили отстойнейшей реализацией с идиотским интерфейсом.
Управлять конфигурацией, говорите. Когда один человек должень убивать по три часа чтобы смерджить дневную разработку это убивает всю идею контроля версий, потому что люди перестают делать комиты.
А особенный кайф я получаю от попыток слить бинарные файлы. НЕТ у этой бл… ой системы возможности сказать я знаю что делаю возьми файл этой версии. Эта поделка криворуких програмистов чесно попытается смерджить 11 Мб файл FrameMaker-а, хотя итак известно что не должна, а потом расспишется в неспособности.
Чтобы влить бинарник нужны танцы с бубном вроде этих www.ibm.com/developerworks/rational/library/07/0424_hu/index.html
Удовольствие также получаю на Remote Client когда попытаюсь смерджить 4 Кб xml, это поделка может вычислять отличия 20-30 мин., это какими руками надо так код писать?
Я работал с многими людьми из разных компаний и никогда не слышал доброго слова о Rational ClearCase, исключение составляли только менеджеры и приближенные к ним люди которым не приходится сталкиватся с этим ужасом каждый день.
Такое впечатление что в Rational IBM нет ни одного юзабилиста, одно сборище технодаунов, потому чтобы создать метку нужно запустить один инструмент, а чтобы применить её к объекту запускаем второй.
Ух ты! Становится интереснее :) Спасибо за отклик.
Итак, по порядку.
Для начала, с какой именно версией КлирКейса ты работал? «Классической» или что-то типа UCM?
Использовал чистую командную строку или какой-то GUI?
Судя по «идиотскому интерфейсу» и ругани на юзалилити — скорее всего, что-то из совсем последнего, как бы даже не сам UCM.
Сам я работал с CC через telnet + FTP, GUI использовал лишь изредка — во время нетривиальных мержей, да и то, только при хорошей связи с сервером.
В основном же работал голыми руками — установка вью, конфигспеков, выполнение мержей и чекинов, помечивание — всё через командную строку. Разумеется, плюс некоторое количество скриптов — как без них.
Признаюсь — для моей работы бОльшего и не надо было, поскольку интеграция состоит из не очень большого количества команд и они максимально эффективно выполняются руками в консоли. Да и отстройка продукта шла там же — так что новомодные ГУИ меня никак не касались.
Разработчики также работали через консоль — и сильной ругани не слышал, хоть сидел и совсем рядом :) У них всего операций было — поставить конфигспек с бэйзлайном, отсрастить ветку, да знай себе делай новые версии на ней. Остальную работу делали мы, СМщики.
В общем, по-видимому, мы говорим о совсем разном инструментарии, сделанном одной фирмой, но в разное время и для разных целей :)))
По этой же причине не буду углубляться в тему мержа бинарных файлов… наша инсталяция клиркейса не умела этого делать… да и не надо было :)
Судя по ссылке, IBM накорню губит один из мощнейших своих продуктов. Жаль.
Да, именно мощнейших! Потому что для много компонентных систм с сотнями разработчиков реальных альтернатив КлирКейсу просто нет. Взять ту же концепцию конфигспека — сколько сил он экономит при формировании сложных взаимосвязей между компонентами, при установлении зависимостей между ними!
К слову, у меня лежит наполовину написанный материал по Клиркейс :) По тому самому клиркейсу, который я использовал и который лежит в основе UCM. Надо бы реанимировать.
Итак, по порядку.
Для начала, с какой именно версией КлирКейса ты работал? «Классической» или что-то типа UCM?
Использовал чистую командную строку или какой-то GUI?
Судя по «идиотскому интерфейсу» и ругани на юзалилити — скорее всего, что-то из совсем последнего, как бы даже не сам UCM.
Сам я работал с CC через telnet + FTP, GUI использовал лишь изредка — во время нетривиальных мержей, да и то, только при хорошей связи с сервером.
В основном же работал голыми руками — установка вью, конфигспеков, выполнение мержей и чекинов, помечивание — всё через командную строку. Разумеется, плюс некоторое количество скриптов — как без них.
Признаюсь — для моей работы бОльшего и не надо было, поскольку интеграция состоит из не очень большого количества команд и они максимально эффективно выполняются руками в консоли. Да и отстройка продукта шла там же — так что новомодные ГУИ меня никак не касались.
Разработчики также работали через консоль — и сильной ругани не слышал, хоть сидел и совсем рядом :) У них всего операций было — поставить конфигспек с бэйзлайном, отсрастить ветку, да знай себе делай новые версии на ней. Остальную работу делали мы, СМщики.
В общем, по-видимому, мы говорим о совсем разном инструментарии, сделанном одной фирмой, но в разное время и для разных целей :)))
По этой же причине не буду углубляться в тему мержа бинарных файлов… наша инсталяция клиркейса не умела этого делать… да и не надо было :)
Судя по ссылке, IBM накорню губит один из мощнейших своих продуктов. Жаль.
Да, именно мощнейших! Потому что для много компонентных систм с сотнями разработчиков реальных альтернатив КлирКейсу просто нет. Взять ту же концепцию конфигспека — сколько сил он экономит при формировании сложных взаимосвязей между компонентами, при установлении зависимостей между ними!
К слову, у меня лежит наполовину написанный материал по Клиркейс :) По тому самому клиркейсу, который я использовал и который лежит в основе UCM. Надо бы реанимировать.
Развёрнуто IBM Remote Client 7.0.1, Multisite, PC Client.
IBM Remote Client даже на 4 МБитной оптике умирает если бросить 11 Мб FrameMaker, причё 100% известно что он смерджить это не сможет, но пытается, в результате на один файл идёт 20 минут, а таких файлов может быть в последние дни перед рэлизом около сотни. Но ведь кроме FrameMaker ещё нужно вливать бинарные компоненты, которые разрабатываются паралельно командами из Индии, Китая, Украины.
Во время работы с Perforce (который тоже не идеален) у меня на интеграцию шёл примерно 1-2 часа в неделю.
Теперь я должен убить 1 день иногда больше. Как по мне у teamlead-а перед релизом всё таки должна быть другая работа, а не следить за интерфейсом Clearcase.
Для билда ихней приблудой пользоватся невозможно, в результате используется сторонний продукт.
Клиент командной строки хорош если ты работаешь с небольшим набором папок, но если конфигурация собирается с несколько тыcяч компонент, то процес подготовки релиза начинает напоминать кошмар на улице вязов.
Как обучить техврайтеров, проэктировшиков плат и остального персонала который от IT очень далёк. Сообщения об ошибках абсолютно неинформативны, ошибки появляются постоянно. Если вылетит ошибка процес останавливается, или ещё хуже приходится начинать всё сначала. Отсутствие атомарных комитов тоже некисло достаёт. Чего стоит невозможность нормально работать с названиями файлов не в Latin-1 кодировке и это в 2009-ом году, главное эта зараз не предупредит, а просто завершит операцию с непонятной ошибкой, главное как-то в систему эти файлы оно проглотила.
Изза невозможности нормально резолвить конфликты вся идея паралельной разработки убивается на корню.
Чем скорее помрёт этот ужас тем будет лучше. Интерфейс PC Client похоже не обновлялся где-то с 2001-го года. Remote Client они только фиксят критические ошибки, судя по блогам и статьям никакого улучшения не предвидится.
Есть много систем над которыми не довлеет груз обратной совместимости и у которых интрефейс дружелюбен к пользователю. Trotoise SVN люди которые впадали в анабиоз от вида P4V осваивали за час. Сейчас чтобы не терять ихменения почти каждая команда вынуждена использовать SVN, а потом переливаем в ClearCase, я для некскольких продуктов помельче тэстирую mercurial.
А насчёт альтернатив, то вы ошибаетесь. Комбайн не нужен, в случае с ClearCase половина инструментов устарела и не поддерживает нормально работу с своременным инструментарием. Если проэкты в студии, то я хочу использовать msbuild и .sln, а не ихнюю поделку, которая нормально работала для С/C++ и то 10 лет назад. Кроме того бутылочным горлышком становится система билда, потому что при ихней политике это должно быть только в одном месте, что при больших командах и сложных многокомпнентных продуктах не всегда опрадано.
Достаточно хорошей системы контроля версий, которая сможет откатить состояние системы на какой-то момент времени, остальная часть реализируется формализированой процедурой и в случае непрерывной интерграции скриптами построения, тэстирования.
Clearcase ведь всего лишь субпродукт, а сам workflow вы определяете в соответствии со своими процедурами. Есть конечно рекомендованый способ вроде Unified Process но это не фиксируется жестко. Даже в subversion эсть рекомендованные практики trunk ваш baseline и branches, правда обычно все работают в trunk ну и tags для фиксирования milestone. А ведь ещё есть mercurial, git и BitKeeper(который я надеюсь вскоре попробовать).
Но если отойти от теории, а посмотреть на реализацию, то увидим что в Clearcase реализацией убили всю идею.
Кстати с версионостью, версия папки не меняется если сменить внутренности, в результате чтобы получить изменения в дереве нужно обойти все ветки ниже и сложность алгоритма где-то выше O(n!), конечно можно оптимизировать этот алгоритм, если добавить кеширование, но судя по всему никакой оптимизации не реализировано, потому что если начать делать мердж время растёт нелинейно при большой вложености и количестве папок, что в случае с ClearCase Remote Client который предназначен для отдалённой работы и должнен пересылать по минимуму просто смертельно, хотя я не анализировал снифером пересылки, просто сужу по времени операций.
Ну и напоследок для компании Буча, Якобсена, Румбаха, Гамы и Хэлма продукт такого качества это как плевок в лицо, возникает вопрос, а использует ли IBM Rational все те практики которые пропагирует.
IBM Remote Client даже на 4 МБитной оптике умирает если бросить 11 Мб FrameMaker, причё 100% известно что он смерджить это не сможет, но пытается, в результате на один файл идёт 20 минут, а таких файлов может быть в последние дни перед рэлизом около сотни. Но ведь кроме FrameMaker ещё нужно вливать бинарные компоненты, которые разрабатываются паралельно командами из Индии, Китая, Украины.
Во время работы с Perforce (который тоже не идеален) у меня на интеграцию шёл примерно 1-2 часа в неделю.
Теперь я должен убить 1 день иногда больше. Как по мне у teamlead-а перед релизом всё таки должна быть другая работа, а не следить за интерфейсом Clearcase.
Для билда ихней приблудой пользоватся невозможно, в результате используется сторонний продукт.
Клиент командной строки хорош если ты работаешь с небольшим набором папок, но если конфигурация собирается с несколько тыcяч компонент, то процес подготовки релиза начинает напоминать кошмар на улице вязов.
Как обучить техврайтеров, проэктировшиков плат и остального персонала который от IT очень далёк. Сообщения об ошибках абсолютно неинформативны, ошибки появляются постоянно. Если вылетит ошибка процес останавливается, или ещё хуже приходится начинать всё сначала. Отсутствие атомарных комитов тоже некисло достаёт. Чего стоит невозможность нормально работать с названиями файлов не в Latin-1 кодировке и это в 2009-ом году, главное эта зараз не предупредит, а просто завершит операцию с непонятной ошибкой, главное как-то в систему эти файлы оно проглотила.
Изза невозможности нормально резолвить конфликты вся идея паралельной разработки убивается на корню.
Чем скорее помрёт этот ужас тем будет лучше. Интерфейс PC Client похоже не обновлялся где-то с 2001-го года. Remote Client они только фиксят критические ошибки, судя по блогам и статьям никакого улучшения не предвидится.
Есть много систем над которыми не довлеет груз обратной совместимости и у которых интрефейс дружелюбен к пользователю. Trotoise SVN люди которые впадали в анабиоз от вида P4V осваивали за час. Сейчас чтобы не терять ихменения почти каждая команда вынуждена использовать SVN, а потом переливаем в ClearCase, я для некскольких продуктов помельче тэстирую mercurial.
А насчёт альтернатив, то вы ошибаетесь. Комбайн не нужен, в случае с ClearCase половина инструментов устарела и не поддерживает нормально работу с своременным инструментарием. Если проэкты в студии, то я хочу использовать msbuild и .sln, а не ихнюю поделку, которая нормально работала для С/C++ и то 10 лет назад. Кроме того бутылочным горлышком становится система билда, потому что при ихней политике это должно быть только в одном месте, что при больших командах и сложных многокомпнентных продуктах не всегда опрадано.
Достаточно хорошей системы контроля версий, которая сможет откатить состояние системы на какой-то момент времени, остальная часть реализируется формализированой процедурой и в случае непрерывной интерграции скриптами построения, тэстирования.
Clearcase ведь всего лишь субпродукт, а сам workflow вы определяете в соответствии со своими процедурами. Есть конечно рекомендованый способ вроде Unified Process но это не фиксируется жестко. Даже в subversion эсть рекомендованные практики trunk ваш baseline и branches, правда обычно все работают в trunk ну и tags для фиксирования milestone. А ведь ещё есть mercurial, git и BitKeeper(который я надеюсь вскоре попробовать).
Но если отойти от теории, а посмотреть на реализацию, то увидим что в Clearcase реализацией убили всю идею.
Кстати с версионостью, версия папки не меняется если сменить внутренности, в результате чтобы получить изменения в дереве нужно обойти все ветки ниже и сложность алгоритма где-то выше O(n!), конечно можно оптимизировать этот алгоритм, если добавить кеширование, но судя по всему никакой оптимизации не реализировано, потому что если начать делать мердж время растёт нелинейно при большой вложености и количестве папок, что в случае с ClearCase Remote Client который предназначен для отдалённой работы и должнен пересылать по минимуму просто смертельно, хотя я не анализировал снифером пересылки, просто сужу по времени операций.
Ну и напоследок для компании Буча, Якобсена, Румбаха, Гамы и Хэлма продукт такого качества это как плевок в лицо, возникает вопрос, а использует ли IBM Rational все те практики которые пропагирует.
Да, чувствуется, что у человека наболело :)
Что могу сказать — подтверждаются мои слова. IBM практически убила отличную идею плохой реализацией.
То, о чем писал я — относится к «core» ClearCase, без GUI, удаленных клиентов и ещё черт-знает-чего. И этот «core» справлялся со своими задачами на отлично. И именно «если конфигурация собирается с несколько тыcяч компонент» — телефоны моторолы собирались не из тысяк компонентов, конечно, однако обхемы кода измерялись сотнями мегабайт и работали с этим добром одновременно сотни человек.
В общем, мы с вами по сути говорим о разных системах. И судя по всему, свежие версии ClearCase я пробовать не захочу :) лучше уж сидеть на SVN, как на нынешнем месте работы, и потихонечку складывать исходники.
По поводу конфигспека (кстати, config spec — именно так он называется; клиентспек — видимо уже неологизм новых релизов клиркейса). Да, возможно использование его *аналогов* в других системах. Тот же SVN::externals может предоставлять что-то схожее. Однако в CC это делается… более «нативно», что ли… Кроме того, с его помощью можно не просто «выхватывать бранчики» — можно делать автоматическое отращивание веток, автоматический чекаут и много чего ещё, что сделает Клиркейс за разработчика.
В общем, в конечном счете, как правильно было замечено, «workflow вы определяете в соответствии со своими процедурами». Именно поэтому я и решил написать теоретическую статью, без приявзки к инструментам — чтобы можно было использовать практики СМ с любым инструментарием.
Что могу сказать — подтверждаются мои слова. IBM практически убила отличную идею плохой реализацией.
То, о чем писал я — относится к «core» ClearCase, без GUI, удаленных клиентов и ещё черт-знает-чего. И этот «core» справлялся со своими задачами на отлично. И именно «если конфигурация собирается с несколько тыcяч компонент» — телефоны моторолы собирались не из тысяк компонентов, конечно, однако обхемы кода измерялись сотнями мегабайт и работали с этим добром одновременно сотни человек.
В общем, мы с вами по сути говорим о разных системах. И судя по всему, свежие версии ClearCase я пробовать не захочу :) лучше уж сидеть на SVN, как на нынешнем месте работы, и потихонечку складывать исходники.
По поводу конфигспека (кстати, config spec — именно так он называется; клиентспек — видимо уже неологизм новых релизов клиркейса). Да, возможно использование его *аналогов* в других системах. Тот же SVN::externals может предоставлять что-то схожее. Однако в CC это делается… более «нативно», что ли… Кроме того, с его помощью можно не просто «выхватывать бранчики» — можно делать автоматическое отращивание веток, автоматический чекаут и много чего ещё, что сделает Клиркейс за разработчика.
В общем, в конечном счете, как правильно было замечено, «workflow вы определяете в соответствии со своими процедурами». Именно поэтому я и решил написать теоретическую статью, без приявзки к инструментам — чтобы можно было использовать практики СМ с любым инструментарием.
Если интересно вот продукт над которым я до недавнего времени работал и продолжу после окончания текущего проэкта. www.cypress.com/PSoCDesigner более 300(только в поставке) компонентов (User Modules + компоненты среды) и ещё около 100 в разработке + всё это в поставляется в разных кофигурациях и паках под разные семейства процесоров.
Всё чудесно работало и собиралось даже с достаточно «бедным» Perforce (кстати Google тоже им пользуется в внутренних разработках), единственным серёзным недостатком Perforce для меня по сути есть отсутствие нормального ветвления. Но в один момент было пролобировано унифицирование систем и все перешли на Clearcase.
Всё чудесно работало и собиралось даже с достаточно «бедным» Perforce (кстати Google тоже им пользуется в внутренних разработках), единственным серёзным недостатком Perforce для меня по сути есть отсутствие нормального ветвления. Но в один момент было пролобировано унифицирование систем и все перешли на Clearcase.
Интересная вещь. А чем занимаешься на проекте? Неужто коллега-СМщик? :)
Нет teamlead но поскольку каждый отвечает за свою часть работы, то в мои обязаности входит обозначение что должно попасть в билд и в какой конфигурации из тех частей над которыми работаем.
У нас нет отдельной должности CM и при даном процесе не вижу нужды, если не считать технических трудностей(ClearCase GUI sucks) то процес чётко формализирован и обозначены рамки в которых нужно двигаться чтобы достичь результата. Хотя так как обозначено чётко движение в сторону програмированных решений и разработка ПО с различных отделов объеденена под новым вицепрезидентом то не исключаю что CM-щики появлятся.
Кстати в этом году выйдет ещё более крутая IDE под новые процесорные ядра PSoC3 и PSoC5. Уже анонсирован и разослан бэтатестерам и ключевым клиентам PSoC Creator https://my.cypress.com/modules/209.cfm?id=10194&rtID=119&rID=37512, безплатно IDE с такими возможностями по моему ещё никто не предлагал.
У нас нет отдельной должности CM и при даном процесе не вижу нужды, если не считать технических трудностей(ClearCase GUI sucks) то процес чётко формализирован и обозначены рамки в которых нужно двигаться чтобы достичь результата. Хотя так как обозначено чётко движение в сторону програмированных решений и разработка ПО с различных отделов объеденена под новым вицепрезидентом то не исключаю что CM-щики появлятся.
Кстати в этом году выйдет ещё более крутая IDE под новые процесорные ядра PSoC3 и PSoC5. Уже анонсирован и разослан бэтатестерам и ключевым клиентам PSoC Creator https://my.cypress.com/modules/209.cfm?id=10194&rtID=119&rID=37512, безплатно IDE с такими возможностями по моему ещё никто не предлагал.
Теперь возьмём clientspec. Да в других системах его нет. Но поскольку в любом случае его содежание опеределяете вы то определить что и из какой ветки брать можно про сборке продукта. В любом случае это нужно для формирования снимка системы для построения, а значит билд система какая-то существует, пусть даже в виде .sln проэкта или perl скрипта.
У меня msbuild конфигурация тоже находится в VCS. При построении он имеет набор конфигурационных файлов что откуда и какой версии взять, причём взять head именно с конкретной ветки или определённую ревизию это всего лишь переменная конфига. И не так уж и много усилий на это затрачивается, если чётко формализировать процедуру и обязать ею пользоватся. (Хотя пока это используется на моих проэктах).
Workflow в любом случае определяется вами, а посему отсутствие clientspec не является смертельным, ни даже бутылочным горлышком.
Если посмотреть на разработку ядра Linux то можем увидеть что продукт с гигантской командой и тысячами компонентов может строить продукт на относительно примитивных инструментах, это не только возможно, а учитывая простоту процеса это даже лучше потому что даёт тот же результат при значительно меньших затратах и усилиях людей сопровождающих процес.
У меня msbuild конфигурация тоже находится в VCS. При построении он имеет набор конфигурационных файлов что откуда и какой версии взять, причём взять head именно с конкретной ветки или определённую ревизию это всего лишь переменная конфига. И не так уж и много усилий на это затрачивается, если чётко формализировать процедуру и обязать ею пользоватся. (Хотя пока это используется на моих проэктах).
Workflow в любом случае определяется вами, а посему отсутствие clientspec не является смертельным, ни даже бутылочным горлышком.
Если посмотреть на разработку ядра Linux то можем увидеть что продукт с гигантской командой и тысячами компонентов может строить продукт на относительно примитивных инструментах, это не только возможно, а учитывая простоту процеса это даже лучше потому что даёт тот же результат при значительно меньших затратах и усилиях людей сопровождающих процес.
Зря вы так про ITIL!
Описанный там Configuration Management совсем не только как вы утверждаете «как он записывает в какую-нибудь базу параметры всего софта»…
Впрочем, ИМХО, ITIL не ориентирован на разработку софта.
А вот перевод SWEBOK на русский есть в прекрасном блоге Сергея Орлика:
sorlik.blogspot.com/search/label/SWEBOK
там не только это, много чего интересного по программной инженерии.
Описанный там Configuration Management совсем не только как вы утверждаете «как он записывает в какую-нибудь базу параметры всего софта»…
Впрочем, ИМХО, ITIL не ориентирован на разработку софта.
А вот перевод SWEBOK на русский есть в прекрасном блоге Сергея Орлика:
sorlik.blogspot.com/search/label/SWEBOK
там не только это, много чего интересного по программной инженерии.
За ссылку спасибо. Хотя сам предпочитаю читать в оригинале :)
Хотя, в части описания СМ, я бы поспорил с автором насчет термина Baseline — у него оно «базовая линия» (линия метро?). У меня он переведен как «базовая конфигурация», см. следующую заметку (http://habrahabr.ru/blogs/pm/67839/).
А в целом, перевод SWEBOK — большой труд, респект.
Хотя, в части описания СМ, я бы поспорил с автором насчет термина Baseline — у него оно «базовая линия» (линия метро?). У меня он переведен как «базовая конфигурация», см. следующую заметку (http://habrahabr.ru/blogs/pm/67839/).
А в целом, перевод SWEBOK — большой труд, респект.
UFO just landed and posted this here
«Делать SCM» — это как «заниматься разработкой». Ты когда настраиваешь своё IDE или выравниваешь строчки кода согласно стандарту кодирования — ты занимаешься разработкой? С одной стороны — да, без этого разработки не будет. С другой — ты ведь не создаешь собственно ПО.
Возвращаясь к Maven — ты, скорее, занимаешься управлением зависимостями. Вещь эта очень близка к CM, но традиционно её отделяют как дисциплину в рамках управления проектами. Короче, это вопрос терминологии :)
Возвращаясь к Maven — ты, скорее, занимаешься управлением зависимостями. Вещь эта очень близка к CM, но традиционно её отделяют как дисциплину в рамках управления проектами. Короче, это вопрос терминологии :)
Огромное вам спасибо за статьи по CM. Я сейчас начну развивать это направление в одной компании. Не знала с чего начать и за что браться, пока не наткнулась на ваши статьи, почти единственные в рунете, в которых всё доходчиво объясняется.
Sign up to leave a comment.
Цикл статей по основам Software Configuration Management