Цикл статей по основам Software Configuration Management

    Пролог


    Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.

    Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.

    А потом увидел статью от камрада altern, в которой он начал рассказывать про СМ. Речь у него пошла несколько в другом ключе — о конкретных инструментах и именовании конфигураций. Поэтому, списавшись с ним, чтобы не пересекаться по тематике наших статей, решил написать об основах того, что называется управлением конфигурацией программных средств.

    Сейчас у меня уже написан материал примерно на 50 тысяч знаков — это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.

    Задача — дать обзор того, чем же вообще является CM, какие задачи он решает и какие техники при этом используются. Речь не будет идти о конкретных системах контроля версий или вообще инструментах — этого добра навалом в сети. Задача — показать универсальные для всех инструментов основы.

    Итак, поехали.

    Что такое CM и зачем он нужен


    Управление конфигурацией

    Для начала определимся, что такое configuration, ведь это слово выведено в заголовок. Конфигурация – это совокупность версий рабочих продуктов. Ключевые слова – «версий продуктов».

    В любом проекте есть рабочие продукты – это может быть маркетинговая документация, требования к конечному продукту, исходные коды, тесты, вспомогательные инструменты. Что считать рабочим продуктом, зависит от проекта (определение будет дано в следующей заметке). Далее, каждый продукт изменяется во времени (в этом ведь смысл разработки), и эти изменения надо как-то учитывать – кто, когда, что именно внёс и зачем он это сделал. Иными словами, учитывать, как появлялись версии продуктов.

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

    Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия CM.

    В англоязычной литературе используется термин Software Configuration Management, сокращенно SCM. Далее для простоты изложения будет использован термин управление конфигурацией и сокращение CM (читается: «сиэм»).

    image
    Схема 1. Элементы, их версии и срезы-конфигурации.

    CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.

    Замечу, что Level 2 – это самый минимальный, начальный уровень зрелости, согласно модели CMM. Level 1 получает «автоматом» организация, завершившая успешно хотя бы один проект по разработке. Поэтому и наличие CM – это минимальное требование для сертификации. Кстати, на втором уровне необходимо иметь, в числе прочего, налаженный процесс тестирования и управления требованиями. Это говорит о том, что с точки зрения стандарта CMMI, правильный configuration management так же важен, как грамотное тестирование и управление требованиями.

    Так в чем же заключается такая ценность CM?

    Направления ответственности CM

    Управление конфигурацией работает на всех этапах жизненного цикла проекта. Появился рабочий продукт (например, файл с исходниками) – он попадает в поле деятельности CM’а. Продукт начал изменяться (мы пишем функциональность) – значит CM должен предоставить средства для контроля над изменениями и автоматически провести сам контроль, где это требуется. Потребовалось разбить работу на команду разработчиков, а то и на несколько – проектный CM предоставляет правила и инструменты для работы. Есть, что предложить заказчику – тогда CM определяет правила стабилизации продуктов разработки и их выпуска. Надо откатиться на произвольный релиз – опять в работе CM. Понадобились метрики по изменениям или документированные политики – ну, вы поняли, к кому обратиться.

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

    Продукты выделили, дальше команда начинает работу. По ходу работы нужно периодически стабилизировать полученные результаты, подводить некоторую черту под наработками, а также определять тот базис, на основе которого будет идти разработка. Это всё также входит в сферу деятельности CM’а.

    Кроме того, CM отвечает за то, что в общем случае называется отслеживанием запросов на изменения. Большинству эта область известна как системы отслеживания ошибок. Ведь никакие изменения не должны проходить спонтанно – каждое из них нужно регистрировать и затем правильным образом назначать и отслеживать – вплоть до попадание в конечный продукт. Вот тут опять остается крайним CM. Изменения в продукты вносим, надо их отслеживать – начинает работать контроль версий. Ничто не будет потеряно – CM на страже.

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

    Ну и, как всегда, «нельзя контролировать то, что нельзя измерить» — (с) Де Марко. Метрики – о них тоже будет сказано пару слов. Где измерения – там и формализация. Другими словами, всё, что связано с CM, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.

    Итак, каковы задачи управления конфигурацией?

    Это:
    • идентификация рабочих продуктов;
    • стабилизация результатов работы и определение базы для дальнейшей работы;
    • отслеживание запросов на изменение;
    • контроль версий;
    • обеспечение параллельности разработки;
    • сбор метрик и формализация применяемых методов.

    Кому интересно прочитать ещё немного теории и проникнуться терминами и формальными описаниями области ответственности – вам к стандартам CMM/CMMI (см. ссылки в конце), там это рассматривается много и плодотворно. Правда, не всегда понятно и почти всегда – сухо и скучно.

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

    Ссылки для расширения кругозора:


    1. en.wikipedia.org/wiki/Software_configuration_management Software Configuration Management на Википедии.
    2. www2.computer.org/portal/web/swebok Software Engineering Book of Knowledge.
    3. www.sei.cmu.edu/cmmi SEI CMMI Website.
    4. www.cmcrossroads.com CM Crossroads the Configuration Management Community.


    Продолжение следует.

    UPD: по просьбам трудящихся, ссылка на вторую часть: habrahabr.ru/blogs/pm/67839
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 42
      +1
      хорошая статья. спасибо. буду ждать с нетерпением продолжения.
        +2
        Как только народ прочитает и прокомментирует эту порцию — закину следующую :)
          –2
          буду ждать… спасибо за труд
        +1
        Если кто что хочет увидеть в будущих стятьях — пишите. Если это уже написано или в планах — дам примерныфй срок, когда будет опубликовано. Если нет — будем обсуждать.
          +1
          Если можно, в список ссылок можно добавить вот этот сборник по практическим руководствам: www.scmpatterns.com, а так же полезную ссылку www.infoq.com/articles/agile-version-control (там, правда, чуть глубже про version control, но подход к управлению конфигурациями тоже прослеживается).
            0
            Спасибо за ссылки, ознакомлюсь.

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

            Насчет включения ссылок — только после ознакомления :)
              0
              Прочитал статью, отлично и просто всё описано.

              Конечно, «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.»
              Однако описаные практики почти универсальны для разных методологий. Нечто похожее я как раз сейчас описываю в разделе «Параллельная разработка», только с упором на компонентную разработку и продуктовые линейки. В общем, позаимствую оттуда идеи для пары картинок :) ибо сам я не художник :)
            +4
            Будет просто замечательно, если сделаете акцент в сторону управления задачами (изменениями/запросами/требованиями). Насколько я знаю, контроль версий файлов, автосборки и багтрекинг достаточно хорошо освещены. А вот как делается правильная постановка задачи и запись ее результатов — мало где описано.
              +1
              Будет отдельный топик про контроль изменений и отслеживание запросов на изменение рабочих продуктов. При этом рабочие продукты могут быть самыми разнообразными — от требований, кода и тестов до конечных бинарников и инсталяционных пакетов. Не важно, в каких именно продуктах отслеживаются изменения — важно делать это постоянно и под контролем.

              Про идентификацию рабочих продуктов будет как раз следующий пост.
              Про отслеживание запросов на изменения — чуть позже, через 1 или 2.

              За интерес спасибо. :)
              0
              > сертификата CMM/CMMI Level 2.

              Нельзя ли подробнее об этом, что зачем, в каких случаях требуется?
                0
                Для начала проще прочитать на Вике:
                en.wikipedia.org/wiki/Capability_Maturity_Model

                От себя — CMM/CMMI в основном нужен как некий сертификат на уровне организации, говорящий о её способности стандартизовать свои внутренние процессы и постоянно их улучшать.
                Можно попробовать внедрить практики «для себя» — просто чтобы подтянуть качество выполняемых проектов.

                Крупные компании, нанимающие подрядчиков, или требуют наличия подобного уровня или сами организуют внутрение аудиты, для оценки способностей организации.

                Остальные же часто сертифицируются «для ветрины».
                  0
                  Т.е. внутренняя процедура, для улучшения управления процессом созданием софта?
                  В качестве требований к процессу организации производства (наподобие ISO9000) в процессе проведения тендеров, например, не выступает?
                    0
                    В первую очередь — это всегда набор внутренних изменений и целый ряд документов, описывающих, как жить в новых условиях организации производства.

                    Внешняя сертификация — это оценка того, как коррелируют между собой 1. внутренняя организация работы 2. документы, описвающие это 3. стандарт, на основе которого сделаны 1 и 2.

                    СММ может быть существенным плюсом при участии в тендере.

                    Насчет одного из требований — встречал упоминание, что какие-то из госстуруктур США (как бы даже не минобороны, поправьте кто-нибудь, если не прав) практически не рассматривает учатников тендаров, у которых нет высокого (от 3) уровня СММ.

                +2
                о ;) люблю хорошо приготовленный топик ;) все с толком и расстановкой ;) я бы удвоил материал для одного поста, читается очень легко ;)
                  +1
                  что ж, приятного… :)

                  Удвоить — не проблема. Боюсь только, что многие «ниасилят», привыкнув читать твиттер :))
                    0
                    По просьбе — следующую часть ровно удвоил и опубликовал :) Посмотрим, осилят ли :)
                    0
                    Хороший пример хорошей статьи — с нетерпением жду продолжения
                      +1
                      Пока особо комментировать по-моему нечего, но вступление очень интересное и грамотно, с толком написанное, что приятно.

                      Интересно какова ваша проектная роль при использовании этих средств, это могло повлиять на изложение.
                        0
                        На проектах для Моторолы я был СМ-инженером в широком смысле этого термина. Занимался как рутинной работой вроде мержа исходников и выпуска билдов, так и координацией работы СМ-команды. Также участвовал в подготовке компании к сертификации на СММ — видимо, оттуда ноги и растут.

                        Ко всему прочему, я уже 8 лет преподаю с нашем Политене второму курсу пары ИТ-специальностей — это тоже накладывает отпечаток на доходчивость изложения Ж-))
                          +2
                          Сделайте микрооглавление перед каждой статьёй — материал будет лучше восприниматься. Тем более, что разбивка в самой статье присутствует.
                            0
                            Спасибо, хорошо.
                        0
                        Статья хорошая. Жду продолжения.
                          0
                          Итак, чтобы было понятно, с чего начинается СМ и что же это за рабочие продукты, подконтрольные СМу, предлагаю вниманию следующую часть:

                          +2
                          Вы ещё отбеливаете, тогда мы идём к вам.
                          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 нет ни одного юзабилиста, одно сборище технодаунов, потому чтобы создать метку нужно запустить один инструмент, а чтобы применить её к объекту запускаем второй.
                            0
                            Ух ты! Становится интереснее :) Спасибо за отклик.

                            Итак, по порядку.

                            Для начала, с какой именно версией КлирКейса ты работал? «Классической» или что-то типа UCM?
                            Использовал чистую командную строку или какой-то GUI?
                            Судя по «идиотскому интерфейсу» и ругани на юзалилити — скорее всего, что-то из совсем последнего, как бы даже не сам UCM.

                            Сам я работал с CC через telnet + FTP, GUI использовал лишь изредка — во время нетривиальных мержей, да и то, только при хорошей связи с сервером.

                            В основном же работал голыми руками — установка вью, конфигспеков, выполнение мержей и чекинов, помечивание — всё через командную строку. Разумеется, плюс некоторое количество скриптов — как без них.

                            Признаюсь — для моей работы бОльшего и не надо было, поскольку интеграция состоит из не очень большого количества команд и они максимально эффективно выполняются руками в консоли. Да и отстройка продукта шла там же — так что новомодные ГУИ меня никак не касались.

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

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

                            Судя по ссылке, IBM накорню губит один из мощнейших своих продуктов. Жаль.

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

                            К слову, у меня лежит наполовину написанный материал по Клиркейс :) По тому самому клиркейсу, который я использовал и который лежит в основе UCM. Надо бы реанимировать.
                              +4
                              Развёрнуто 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 все те практики которые пропагирует.
                                0
                                Да, чувствуется, что у человека наболело :)

                                Что могу сказать — подтверждаются мои слова. IBM практически убила отличную идею плохой реализацией.

                                То, о чем писал я — относится к «core» ClearCase, без GUI, удаленных клиентов и ещё черт-знает-чего. И этот «core» справлялся со своими задачами на отлично. И именно «если конфигурация собирается с несколько тыcяч компонент» — телефоны моторолы собирались не из тысяк компонентов, конечно, однако обхемы кода измерялись сотнями мегабайт и работали с этим добром одновременно сотни человек.

                                В общем, мы с вами по сути говорим о разных системах. И судя по всему, свежие версии ClearCase я пробовать не захочу :) лучше уж сидеть на SVN, как на нынешнем месте работы, и потихонечку складывать исходники.

                                По поводу конфигспека (кстати, config spec — именно так он называется; клиентспек — видимо уже неологизм новых релизов клиркейса). Да, возможно использование его *аналогов* в других системах. Тот же SVN::externals может предоставлять что-то схожее. Однако в CC это делается… более «нативно», что ли… Кроме того, с его помощью можно не просто «выхватывать бранчики» — можно делать автоматическое отращивание веток, автоматический чекаут и много чего ещё, что сделает Клиркейс за разработчика.

                                В общем, в конечном счете, как правильно было замечено, «workflow вы определяете в соответствии со своими процедурами». Именно поэтому я и решил написать теоретическую статью, без приявзки к инструментам — чтобы можно было использовать практики СМ с любым инструментарием.

                                  0
                                  Если интересно вот продукт над которым я до недавнего времени работал и продолжу после окончания текущего проэкта. www.cypress.com/PSoCDesigner более 300(только в поставке) компонентов (User Modules + компоненты среды) и ещё около 100 в разработке + всё это в поставляется в разных кофигурациях и паках под разные семейства процесоров.
                                  Всё чудесно работало и собиралось даже с достаточно «бедным» Perforce (кстати Google тоже им пользуется в внутренних разработках), единственным серёзным недостатком Perforce для меня по сути есть отсутствие нормального ветвления. Но в один момент было пролобировано унифицирование систем и все перешли на Clearcase.
                                    0
                                    Интересная вещь. А чем занимаешься на проекте? Неужто коллега-СМщик? :)
                                      +1
                                      Нет 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 с такими возможностями по моему ещё никто не предлагал.
                                        0
                                        Стало быть, ты выполняешь как раз роль СМщика! Подготовка релизов и т.п. — это как раз его задача.

                                        Ну то ж… успехов в этом нелегком деле :)

                                        P. S. Жаль, не было возможности у тебя познакомиться с «правильным» Клиркейсов — иначе всё сложилось бы иначе :)
                              0
                              Теперь возьмём clientspec. Да в других системах его нет. Но поскольку в любом случае его содежание опеределяете вы то определить что и из какой ветки брать можно про сборке продукта. В любом случае это нужно для формирования снимка системы для построения, а значит билд система какая-то существует, пусть даже в виде .sln проэкта или perl скрипта.
                              У меня msbuild конфигурация тоже находится в VCS. При построении он имеет набор конфигурационных файлов что откуда и какой версии взять, причём взять head именно с конкретной ветки или определённую ревизию это всего лишь переменная конфига. И не так уж и много усилий на это затрачивается, если чётко формализировать процедуру и обязать ею пользоватся. (Хотя пока это используется на моих проэктах).
                              Workflow в любом случае определяется вами, а посему отсутствие clientspec не является смертельным, ни даже бутылочным горлышком.
                              Если посмотреть на разработку ядра Linux то можем увидеть что продукт с гигантской командой и тысячами компонентов может строить продукт на относительно примитивных инструментах, это не только возможно, а учитывая простоту процеса это даже лучше потому что даёт тот же результат при значительно меньших затратах и усилиях людей сопровождающих процес.
                              +1
                              Зря вы так про ITIL!
                              Описанный там Configuration Management совсем не только как вы утверждаете «как он записывает в какую-нибудь базу параметры всего софта»…
                              Впрочем, ИМХО, ITIL не ориентирован на разработку софта.

                              А вот перевод SWEBOK на русский есть в прекрасном блоге Сергея Орлика:
                              sorlik.blogspot.com/search/label/SWEBOK
                              там не только это, много чего интересного по программной инженерии.
                                0
                                За ссылку спасибо. Хотя сам предпочитаю читать в оригинале :)

                                Хотя, в части описания СМ, я бы поспорил с автором насчет термина Baseline — у него оно «базовая линия» (линия метро?). У меня он переведен как «базовая конфигурация», см. следующую заметку (http://habrahabr.ru/blogs/pm/67839/).

                                А в целом, перевод SWEBOK — большой труд, респект.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  «Делать SCM» — это как «заниматься разработкой». Ты когда настраиваешь своё IDE или выравниваешь строчки кода согласно стандарту кодирования — ты занимаешься разработкой? С одной стороны — да, без этого разработки не будет. С другой — ты ведь не создаешь собственно ПО.

                                  Возвращаясь к Maven — ты, скорее, занимаешься управлением зависимостями. Вещь эта очень близка к CM, но традиционно её отделяют как дисциплину в рамках управления проектами. Короче, это вопрос терминологии :)
                                  +1
                                  Огромное вам спасибо за статьи по CM. Я сейчас начну развивать это направление в одной компании. Не знала с чего начать и за что браться, пока не наткнулась на ваши статьи, почти единственные в рунете, в которых всё доходчиво объясняется.
                                    0
                                    Спасибо :) Можете также посмотреть блог отставного сиэмщика, указанный у меня в профиле — там я также публикую заметки, которые могут быть неинтересными здешнему контингенту.
                                      +1
                                      Ваш блог уже в избранном)
                                        0
                                        Извиняюсь, ссылки на блог не нашел.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое