Аудит системы контроля версий, ч. I

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


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


    В этом документе описывается только анализ системы. Способы решения проблем,
    выявленных при анализе, будут обсуждаться отдельно.




    I. Список веток


    Выписываем в столбик список веток.

    На этом этапе не надо придумывать новых веток, «как хотелось бы».
    Просто выписываем в столбик список существующих, даже если она всего одна.

    Как оно вообще может быть: примеры. Для тривиальных (или плохо организованных)
    проектов этот список состоит из одного пункта: «ствол». Для чуть более
    контролируемых проектов появляется ветка «production». Часто используются
    ветки под крупную задачу (feature branches): «новый дизайн проекта»,
    «рефакторинг системы классов», «эксперимент Б». Некоторые системы контроля
    версий способствуют тому, что ветки под задачу могут быть крошечными и
    короткоживущими (task branches) — вплоть до одного-двух коммитов. Иногда
    используются ветки под девелопера: каждый работает в своей ветке и регулярно
    сливает изменения на ствол, убедившись в их качестве. Иногда используются
    временные ветки для QA, со своим уникальным процессом.

    Долгоживущие ветки выписываются как есть. Временные короткоживущие ветки,
    такие как ветки под задачу или qa-ветки, занимают одну строчку во
    множественном числе.



    Пример списка веток:

    trunk

    production

    ветки под задачу



    II. Чеклист по веткам


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

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

    II.1. Когда, кто, откуда и на какой срок создаёт ветку?


    Четыре вопроса: Кто создаёт эту ветку? При каких условиях он её создаёт?
    Каково начальное содержимое ветки? Каков срок жизни ветки?

    Пример 1:

    • ветка «production» создаётся в момент, когда общепринято, что проект
      готов к внедрению, и разработка стабилизируется;


    • ветку создаёт ведущий разработчик;

    • ветка создаётся на основании текущего состояния транка;

    • ветка живёт «вечно».


    Пример 2:

    • ветка под задачу создаётся при появлении относительно большой и сложной
      задача, которую нецелесообразно разрабатывать непосредственно в
      транке;


    • ветку создаёт разработчик, которому поручена задача;

    • ветка создаётся на основании текущего состояния транка;

    • ветка живёт, пока задача не будет в целом сделана (после реинтеграции в
      транк доработки по задаче происходят непосредственно в транке).



    Здесь в принципе уже может появиться понимание, что какой-то из аспектов
    непродуман. Помечаем вопрос как проблемный и движемся дальше.



    II.2. Откуда берутся изменения на ветке?


    Для нашего дальнейшего обсуждения давайте различать изменения (changesets) и
    коммиты (commits). Будем называть «коммитами» только те изменения, которые
    делаются разработчиком руками (грубо говоря, написанный код). «Изменения» — более общее понятие, включающее также автоматические слияния с других веток.

    Итак, два вопроса: Кто вносит изменения на ветку? Какова природа этих
    изменений?

    Основные классы вносимых изменений, которые необходимо различать:

    • коммиты (код, написанный разработчиком);

    • автоматические слияния других веток (указать, с каких);

    • ручные слияния отдельных коммитов с других веток (с каких?) (обычно
      встречается при багфиксах старых версий на maintenance-бранчах);

    • обновление версий внешнего кода (как часто?) (встречается на vendor
      branches, tracking branches).


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

    Пример 1:

    • разработчик Вася, отвечающий за продакшен, автоматически сливает на
      ветку production изменения с транка;


    • больше никаких изменений на ветку production никем не вносится.


    Этот пример означает, что даже быстрые фиксы обязаны проходить через транк.

    Пример 2:

    • разработчик Петя при выходе новой версии nginx заливает в vendor branch
      «nginx-orig» его исходники;


    • больше никаких изменений на ветку «nginx-orig» никем не вносится.


    Пример 3:

    • все разработчики проекта свободно коммитят на trunk;

    • разработчики, занимающиеся крупными задачами, автоматически сливают
      изменения со своих feature branches на trunk;


    • больше никаких изменений на trunk никем не вносится.




    II.3. Куда уходят изменения, внесенные на ветку? Кто это делает?


    Здесь возможны три варианта:

    • «наружу» (вынос версии сайта на публику, генерация инсталлятора для
      выкладывания на download.com, etc.);

    • сливаются на другую ветку (указать, какую);

    • выбрасываются (для экспериментальных веток).


    Пример 1:

    • разработчик Дима с помощью deploy-скрипта регулярно выносит текущую
      версию «production» на публику.



    Пример 2:

    • изменения в feature-ветках при завершении работы над задачей сливаются
      в trunk владельцем задачи.



    II.4. Кто отвечает за состояние ветки?


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

    Важно точно убедиться, что человек, вносящий изменения, понимает, что его
    работа — это не механическая заливка на ветку свежего тарболла, а некоторая
    интеллектуальная работа. Самый простой пример — отслеживание open-source
    проекта. Компилируется ли оно? Нет ли в нём известных багов? Вообще, именно
    этот вопрос требует максимального объема коммуникации.

    Пример 1:

    • за качество кода на trunk'е — солидарная нежесткая ответственность.
      Ломать сборку запрещено. Коммитить код без тестов или тем более не
      проходящий тесты — порицается. Количество багов желательно уменьшать, а
      количество фич — увеличивать.



    Пример 2:

    • за качество ветки «golden», которая
      будет записана на компакт-диски в количестве 10 тысяч экземпляров и
      отправится в магазины, отвечает лично Релизов Авдотий Валерьевич. Ошибки
      на этой ветке наказываются лишением премии, а ошибки, приводящие к выбросу
      партии дисков— переводом на младшую должность. Место для подписи:
      _______.



    II.5. Смысл ветки.


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

    Пример 1:

    Trunk предназначен для текущей слабоструктурированной разработки очередной
    версии.


    Пример 2:

    Feature-ветки предназначены для работы над крупными переделками структуры
    кода с большим ожидаемым временем нестабильности.


    III. Действующие лица и исполнители.


    Для контроля целостности составленного анализа необходимо перечислить всех
    упомянутых в нём сотрудников (или групп сотрудников) и для каждого кратко
    перечислить:

    • какие изменения в какие ветки он имеет право вносить;

    • за какие ветки он отвечает;

    • с каких веток он выносит код наружу.


    Формально этот пункт избыточен (вся информация уже собрана ранее), но
    требуется для, например, выяснения, не перегружен ли тот или иной сотрудник.



    IV. Пример документа, взят с реального проекта


    Список веток:

    • trunk;

    • production;

    • feature-ветки.


    Trunk


    Trunk был создан в момент начала проекта ведущим разработчиком с нуля и будет
    жить вечно.

    Разработчики С. и М. свободно коммитят в trunk; верстальщики С. и Н. свободно
    коммитят в trunk; из feature-веток изменения автоматически сливаются в trunk;
    больше никаких изменений на trunk никем не вносится.

    Изменения с trunk сливаются на ветку «production» одним из разработчиков (по
    принципу КПТИП); изменения с trunk сливаются на feature-ветку владельцем этой
    ветки.

    За качество кода на trunk существует солидарная ответственность. Каждый
    разработчик отвечает за свои коммиты. За коммиты, внесенные верстальщиками, не
    чувствует своей ответственности никто. (ПРОБЛЕМА!)

    Trunk предназначен для текущей слабо формализованной разработки проекта.

    Ветка «production»


    Ветка «production» была создана в процессе внедрения проекта в эксплуатацию
    ведущим разработчиком на основании текущего состояния trunk и будет жить
    вечно.

    Разработчики С. и М. (в зависимости от того, чья фича выносится), сливают
    изменения с trunk в production; больше никаких изменения на production никем
    не вносится.

    Изменения с production с помощью deploy-скрипта выносятся на staging, а затем
    на боевой сервер и становятся доступны широкой публике. Выносит один из двух
    разработчиков (в зависимости от того, чья фича выносится).

    За качество кода на «production» существует солидарная ответственность.
    Выносящий разработчик отвечает за качество вынесенной функциональности
    (своей). Как показал опрос, за коммиты от верстальщиков, пробравшиеся на
    production, не чувствует своей ответственности никто. (ПРОБЛЕМА!)

    Production предназначен для выкладывания стабилизированных изменений.

    Feature-ветки


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

    Хозяин ветки свободно коммитит в feature-ветку; хозяин ветки может обновлять
    состояние feature-ветки, заливая на неё изменения, происходящие в trunk;
    больше никто никаких изменений в feature-ветку не вносит.

    За качество кода на feature-ветке отвечает её владелец.

    Feature-ветки предназначены для временного хранения нестабильных наборов
    изменений.

    Заключение


    В этой схеме видно несколько проблем с процессом разработки.

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

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



    Методам решения этой и других проблем мы посвятим нашу следующую статью.



    P.S.: у нас есть ряд вакансий: http://undev.ru/.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 27
    • +2
      в комментах можно описывать свои сложности, попробуем что-нибудь придумать
      • +1
        production ветки еще так же очень часто называются tags ветки… Ну по крайней мере у нас на проекте так было.
        • 0
          ты что-то путаешь

          Тэги — это пометки конкретных версий кода, например WINDOWS-98-RELEASE.

          К веткам они имеют очень опосредованное отношение.
          • –1
            «Тэги» в SVN — это отдельные ветки, видимо копии продакшона разных дат, в которые по договорённости никто не комитит. Иногда (не всегда, ибо ставить её относительно геморно) с защитой от комитов на уровне сервера…
            • 0
              не понимаю, зачем нужно вводить такое слияние

              «тэги — это ветки, но в отличие от веток, в них никто не коммитит».

              кроме того, они нужны для совершенно другого

              у них вообще разный набор операций

              это разные «типы данных»

              зачем же?
              • 0
                хм… если папку на диске обозвать «библиотекой» она от этого не перестанет быть папкой на диске?

                может я что-то путаю, но в SVN нету другого «типа данных» для тэгов. Обходятся наличием договорной ветки в структуре папок, за счёт того, что создание такой ветки — операция в SVN очень дешёвая в смысле дискового пространства.
                • 0
                  так это проблема Svn — что у неё нет другого типа данных :)

                  по факту же тэг и ветка (безотносительно конкретной СКВ) — это две принципиально разные сущности

                  то, что в Svn — это просто файловые пути в репозитории + набор договоренностей, которые невозможно enforce — это на самом деле реальная засада! думать мешает, мешает простраивать нормальное отображение между workflow и toolflow, мешает обучать.
                  • 0
                    Дык кто сказал, что это проблема? Это бонус у них такой… ;)

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

                    А смотреть с другой точки зрения — вставлять самому себе палки в колёса. Или, что вернее — ехать на поезде поперёк рельсов. Если хочешь ездить поперёк — садись на автомобиль. Хочешь вообще перпендикулярно — на вертолёт. Или на щит проходческий.

                    Критиковать одно средство передвижения с позиций другого получается громко, но смешно. Это я к тому, что подводить правила передвижения и обозначать проблемы в разных системах исходя с точки зрения одной из них — не получится. То, что в одной системе проблема — не проблема в другой. И наоборот. Обучать системе надо проникнувшись её собственной логикой, особенно когда она есть. Тогда проблем ни в обучении, ни в думании не будет.

                    Будет лишь искусственное сужение кругозора, но где без него?
                    • 0
                      если проблему назвать бонусом — от этого она не перестанет быть проблемой

                      поэтому дальше я комментарий читать не буду

                      время экономлю

                      • 0
                        зря… дальше идут слова «А если серьёзно » и то, что я писал, чтобы прочитали.
                      • 0
                        > А если серьёзно — при пользовании любой системы максимальные плюсы и простоту
                        > использования получаешь, вставая на точку зрения её проектировщиков, и действуя в
                        > рамках предлагаемой ими логической модели.

                        этот тезис верен только при одном дополнительном условии: «нельзя изучать альтернативы»

                        слава богу, в 2008 году это не так

                        и изучив альтернативы, мы чётко понимаем, что отсутствие выделенных понятий ветки и тэга — это проблема в Subversion

                        изнутри конечно оно может и не казаться проблемой

                        «у нас так спокон веку делают»

                        но при этом теряется возможность осознать, какой handicap ты на себя (возможно) навесил

                        • 0
                          Кстати, где-нибудь есть почитать, почему это является проблемой? В чём именно «handicap» использования данной логической парадигмы?
                          • 0
                            я осознал безнадёжную неадекватность Subversion только после того, как понял устройство репозитория Git

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

                        • 0
                          блин
                          отвечаю ерунду и на ерунду

                          у вас опять нарушение логических уровней

                          вы говорите про «использование» веток

                          я говорю про их концептуальную структуру

                          мой длинный тупой комментарий отзываю

                          • 0
                            эээ… Вы о чём? не понял ни про уровни, ни про коммент…

                            похоже, сей чат стоит замять, за непониманием друг друга.
                            • 0
                              вы говорите про «использование» веток

                              я говорю про их концептуальную структуру

                              поэтому у вас получается длинная увлекательная история про горнопроходческий щит, которая к моему тезису не имеет ни какого отношения

                      • 0
                        как невыносимо меня заколебала эта история про «в svn дешево создавать ветки»

                        лучше бы там стояла искусственная задержка на две минуты, чтобы не было иллюзий.
                        • 0
                          и вот ещё одно нарушение логических уровней

                          что значит «папка на диске».

                          нет такой вещи, как «папка на диске».

                          есть специальный inode с некоторыми флагами + формат хранения direntries

                          тогда этот псевдопарадокс становится хоть как-то валидным

                          • 0
                            В виндовс — есть. И в мак-ос есть. У них логика такая. И то, что можно и хард-линков понаделать — это навороты над такой логикой, которые её слегка ломают и желают непоследовательной. От того они и скрыты от рядового юзера.

                            И в VSS есть, и в SVN — тоже есть. Именно папки, и именно где-то «на диске» — в отдельном цельном непротиворечивом дереве, если не вылазить за пределы логики авторов.
              • +1
                насколько я понимаю — все ветки и прочее это как говорят — конвенции. Как договоримся так и будем. У нас все релизы лежали в tags в и имя там было — версия + дата.
                • 0
                  всё правильно

                  но ведь вы туда не коммитили после создания

                  то есть это была не ветка
                  а тэг
                  • +1
                    конечно не коммитили. она была нужна только для того что бы если пользователь пишет об ошибке — взять этот таг и на нем оттестить и внести изменения если надо в транк. Мне показалось, что в production тоже не часто комитят… :) или я плохо понял статью.
                • 0
                  А можно где-нить в начале статьи написать, под какую систему контроля версий эта статья заточена?

                  И непонятно, где именно недостатки и проблемы выявляются. Что именно предлагается считать недостатками и проблемами, и на каком основании?

                  В общем, я понял: вводит в заблуждение фраза «В этом документе описывается только анализ системы. Способы решения проблем, выявленных при анализе, будут обсуждаться отдельно.». Но в статье нет ни слова про само выявление проблем, приведена только схема для описания состояния. Возможно неплохая, но всё же — это не анализ, а подготовка информации для него.
                  • 0
                    хотя, зачатки анализа — типа обнаружение отсутствия ответственности за изменения от верстальщиков — есть, да. Но разве это анализ?
                    • 0
                      по-моему, это анализ текущего состояния системы в отношении структуры потоков изменений

                    • 0
                      естественно, ни под какую не заточена

                      дурацкая получилась бы статья :)

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