Software Configuration Management // отслеживание запросов на изменение

    Вместо предисловия

    И снова доброго времени суток!

    Продолжаю цикл заметок об основах управления конфигурацией программных средств. Чтобы долго не пересказывать краткое содержание предыдущих двух серий, предлагаю ссылки на них:
    1. Цикл статей по основам Software Configuration Management. О том, что такое СМ, каковы его задачи и за что отвечает в рамках проекта CM-инженер.
    2. Software Configuration Management // Конфигурации и baselines. О том, что такое рабочий продукт в терминах SCM, что такое конфигурация, как она стабилизируется, а так же что такое базовые конфигурации — baselines.
    В этой заметке речь пойдет о том, что большинство называют bugtracking systems. Мы посмотрим на этот класс задач и инструментов с более обобщенной точки зрения.


    Отслеживание запросов на изменение


    Для начала, как вообще возникают изменения на проекте? Вариантов всего несколько:
    • создается новая функциональность продукта;
    • функциональность или внутренняя структура изменяются в ходе плановых доработок (например, рефакторинга);
    • исправляются найденные ошибки.
    Первые два вида иногда объединяются. Однако чаще всего он отделяются друг от друга – просто потому, что это действительно разные вещи. Конечно, бывает, что для исправления ошибки нужно сделать рефакторинг или же написание функциональности устраняет некоторые проблемы. Но в этих случаях всё сводится к тому, какой процесс работы над изменениями, и какая терминология приняты в рамках проекта.

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

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

    Итак, есть потребность в изменениях, и есть тот, кто эту потребность озвучит. Остается начать движение. Началом движения является подача запроса на изменение. Запрос на изменение – это предложение об усовершенствовании продукта, выраженное в виде записи в системе отслеживания запросов на изменения. В англоязычных источниках такие запросы называются change request (CR). Встречается также термин problem or change request (PCR). В дальнейшем будем использовать аббревиатуру CR (читается «сиар»).

    В свою очередь, система отслеживания запросов на изменения – это программная среда, позволяющая производить учет предложений на изменения продукта и управление ответственностью за них. Ключевые слова во всей цепочке терминов – запрос, изменение, и отслеживание ответственности. В русскоязычных источниках часто используется термин «система отслеживания ошибок». В англоязычной литературе встречаются change request management system, bugtracking system, issue tracking system.

    Как правило, хранилищем в подобных системах выступает БД, где один CR – это одна запись (чаще — связанный набор записей) в ней. CR после заведения имеет следующую обязательную информацию:
    • кто завел запись (submitter);
    • краткое название записи (subject);
    • использованная версия изменяемой системы;
    • подробное описание запроса или проблемы.
    Также может быть добавлена просто полезная информация (она может быть объявлена как обязательная, в зависимости от принятого процесса разработки):
    • описание ожидаемого поведения системы (для ошибок);
    • конфигурация ПО и аппаратной части;
    • фрагменты журнала работы системы («логи»).
    Далее весь жизненный цикл записи – это последовательное назначение ответственного на разных этапах работы и добавление информации, необходимой для решения задачи. Как правило, устройство систем отслеживания можно свести к двум моделям:
    • конечный автомат (finite state-machine, или машина состояний), где каждое состояние характеризуется своим набором полей;
    • запись, у которой по ходу работы меняют содержимое имеющихся полей и к которой добавляют комментарии.
    Вторых гораздо больше, чем первых. Наибольшее различие – во внутреннем устройстве. Внешне же оно выражено только тем, можно ли добавлять новую структурированную информацию по ходу работы над CR. Но, независимо от типа системы, работа над записями идет в целом одинаковым образом. Ведь главное – это организация процесса разработки, а инструменты – это следствие его выбора и оптимизации.

    Посмотрим на типовой сценарий. Запись заведена, нужно начинать работать. Однако никакие изменения не должны вноситься бесконтрольно. Поэтому перед началом работы нужно получить одобрение менеджмента, который отвечает за функциональность, затронутую запросом на изменение. Роль менеджмента выполняет Configuration Control Board (группа контроля конфигурации) – группа, обладающая в рамках проекта правами на управление изменениями в рамках проекта. Также иногда используется термин Change Control Board и сокращение CCB.

    Простой сценарий


    Для дальнейшей работы возьмем систему отслеживания в виде машины состояний – так будет более наглядно. Набор состояний на схеме 1 – минимально необходимый, он может быть расширен до большего размера и разбит на нескольких шаблонов жизненных циклов. Этот набор возьмем для дальнейшего описания.

    Схема 1. Жизненный цикл запроса на изменение
    Схема 1. Жизненный цикл запроса на изменение

    Первое состояние, в которое попадает любая запись, начальное. На приложенной схеме это New. На этом этапе создатель записи вносит все начальные данные, требуемые проектным процессом разработки. Далее CR попадает в поле зрения CCB. Оно принимает решение, кому из разработчиков отдать проблему для решения.

    Для того, что отдать CR в работу, запись переводится в следующее состояние – Assigned («приписано к ответственному»). Одновременно запись «назначается» на разработчика – т.е. он становится за неё ответственным.

    Однако приписать задачу кому-то – ещё не означает, что задача сразу же начнет решаться. На одного разработчика ведь может быть назначено несколько задач – одна важней другой и все надо сделать ещё вчера. Поэтому когда разработчик на самом деле начинает заниматься задачей – он переводит запись в состояние Opened («работа начата»). CCB, отслеживающее работу, видит, что задача взята в оборот. Сама задача при этом, как правило, остается «приписанной» к разработчику.

    По ходу работы ответственные могут меняться, в зависимости от того, кто владеет кодом, который влияет на описанное в CR поведение. Переназначения делает CCB. Кроме того, может выясниться, что проблема уже кем-то найдена и на неё был заведен свой CR. В этом случае проблема дуплицируется, т.е. закрывается и в соответствующем поле добавляется номере записи, которая была заведена ранее. С этого момента запись считается закрытой. Может также выясниться, что описанная проблема не является ошибкой в работе (т.е. это WAD, works as designed) или же запрошенная функциональность не может быть реализована в силу разных причин. В этом случае запись терминируется, т.е. закрывается с комментариями о том, почему работа над проблемой продолжена не будет.

    Если же всё-таки работа продолжается, то рано или поздно она заканчивается – разработчик внёс необходимые изменения и готов отдать их на дальнейшую интеграцию. В этот момент он переводит запись в состояние Resolved («исправлено» или «решение найдено»). Этим шагом назначенный для решения снимает с себя ответственность и показывает те изменения, которые, по его мнению, должны решить задачу. В этом состоянии CCB вновь должна назначить ответственного. Он проверит, что задача, поставленная в CR, действительно решена правильно и всё работает как минимум не хуже, чем было до её решения. Поэтому на этом этапе ответственным назначается или кто-то из тестеров, или же сам автор записи. После назначения проверяющий («верификатор», «verifier»), которым зачастую является автор запроса, начинает проверку. Результатом является 2 исхода:
    • перевод в начальное состояние, если задача не решена;
    • перевод в состояние Closed («закрыто»), если исправлена ошибка или работает новая функциональность, описанная в запросе.
    После чего изменения интегрируются в основной код продукта. За это отвечает уже СМ-инженер проекта и на него заводится отдельная запись в системе.

    Об реализации и тонкой настройке


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

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

    Моё мнение — надо выбирать системы, позволяющие гибко задавать цикл работ. Хотя бы для того, чтобы заложенная когда-то кем-то неведомым схема работы не стала для вашего проекта догмой. Со временем за её рамки трудно выйти из-за ограничений инструментария и проекту начинает становиться «тесно». Так что гибкая настройка — наш выбор!

    Реализация систем отслеживание запросов на изменения – едва ли не любимейшее занятие программистов всего мира. Кто-то считает, что его система-то уж точно затмит все имеющиеся. Кто-то уверен, что в остальных чего-то не хватает из того, что надо ему. А кто-то просто делает это ради собственного удовольствия. Каждому – своё. Если кто не захочет изобретать своё двухколесное средство передвижения, может ознакомиться с существующим велопарком. Ну и подобрать бицикл, что лучше всего подходит для его задачи. К слову, автору довелось принять некоторое участие в разработке упомянутого в приведенном списке eTraxis. Его и порекомендую, пользуясь случаем.

    А как же CM-инженеры?


    Запросы на изменение отслеживать научились. Какова роль CM-инженеров проекта? На них лежит ответственность за:
    • внедрение систем отслеживания в процесс разработки;
    • разработку политик использования этих систем;
    • отслеживание выполнения установленных правил.

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

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


    1. http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems — сравнение систем учета запросов на изменение.
    2. http://www.etraxis.org/ — система отслеживания запросов, в создании которой автор принимал активное участие.
    3. Также смотрите ссылки в предыдущих статьях, ссылки на них присутствуют в начале заметки.


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

    Так что, продолжение следует.
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 19
    • +2
      А коннектор для плагина Mylyn Eclipse'a у вашего etraxis есть?
      • 0
        Пока нет. Но создатель etraxis периодически читает комменты к моим заметкам — думаю, его это заинтересует.
      • 0
        В упомянутой вами системе etraxis вижу шероховатость в виде ID, как я понял номер единый, но добавляется статус то ли тип, я не понял. По мне это плохо, что делать есть запрос модифицируется, в моей системе я просто поменяю тип с Defect на Enchancement, а в вашей я так понимаю, нужно этот закрыть и открыть новый иного типа. Я сужу только по скриншотам, возможно у вас иначе, но тогда скриншоты плохо подобраны.
        • 0
          Как говорится, это не бага, это фича :) Да, действительно, нумерация ID у всех сквозная. Это позволяет внутри самим записейчас ссылаться на другие записи, например, написав просто rec#1234 — оно будет преобазовано в правильную ссылку, в префиксом. Сам префикс сделан для чисто зрительного отличия записей, функциональной нагрузки он не несет. Если скопировать URL записи — в нём не будет упоминания префикса.

          Насчет типов. etraxis относится к системам, где запись — это машина состояний. Выбрав шаблон записи при её создании, пользователь выбирает и тип жизненного фикла, со своим набором состояний и полей. Соответственно, смена типа записи (читай — жизненного цикла) невозможна после её заведения. Если требуется кардинально поменять работу с баго или фичей — заводится новая запись, а существующая дуплицируется на неё (я написал в статье, что это).
        • +1
          неудобно, что нет online demo
          и кстати, имхо, чуть более «правильно» рисовать не графики, а гистограммы.
          графики предназначены для визуализации непрерывных функций, а у вас она дискретная.
          • 0
            Да, про online demo я автору давно намекал :) Возможно, через какое-то время оно появится. Пока что можно поставить сборку на основе XAMPP — ставится быстро и всё работает сразу.

            Гистограммы — да, это мысль.
            • 0
              линукс на работе %)
              скачал тарбол, честно пытаюсь настроить всё по www.etraxis.org/docs-example.php
              да, всё _очень_ гибко, но для человека, который видит систему впервые — очень сложно. первоначальная настройка до потребного состояния, чувствуется, будет весьма продолжительной и нудной :-)
              как насчёт preset'ов? :-)
              • 0
                хз, всё по экзамплу сделал, faq прочитал… не могу получить кнопку create :-(
                • 0
                  Права выставил?
                  • 0
                    всё ок :-) был невнимателен
                  • 0
                    пардон, кнопку получил. продолжаем смотреть :-)
            • 0
              Кстати, сборка XAMPP есть под линукс, см. www.etraxis.org/demo.php

              Насчет preset:
              www.etraxis.org/docs-quick-start.php

              Там можно импортнуть xml с типичным багрепортом.
              • 0
                а, чудесно. спасибо :-)
                • 0
                  кстати, а почему при создании нового тикета он пишет Step 3/3?
                  где предыдущие 2?
                  • 0
                    Step 1 — выбор проекта (у тебя он всего один)
                    Step 2 — выбор шаблона (у тебя он опять же один)
                    Так что, не требуя на первых двух шагах выбор 1 опции из 1 — переходит сразу к сути.
                    • 0
                      продолжая надоедать: открытой регистрации нет? (ищу замену trac'у)
                      • 0
                        Нет. Только гостевой доступ, предварительно заведенный юзеры и LDAP.
                        • 0
                          А в планах?
                          • 0
                            Да, в планах есть, автор просто забыл добавить в Roadmap :)

                            К слову, это ведь Open Source — стало быть, если система понравится при ближайшем рассмотрении — можешь сам дописать ;) архитектура довольно проста.

                            И ещё — автор накинул ссылочку на онлайн-демо:
                            demo.demolabo.com/etraxis/en/records/index.php
                            юзер: demolabo, пароль: demolabo

                            Но:
                            1. версия не самая свежая
                            2. автор никакой ответственности за инсталляцию не несет, это посторонняя компания

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

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