Зупинка розробників, що здійснюють неправильну гілку DVCS

Проблема

Я працюю над програмним проектом, який налічує близько 10 розробників, ми ділимося вихідним кодом через Mercurial. У нас є галузь розвитку та виробництва на випуск. Під час проекту ми неодноразово мали вихідний код з однієї гілки, тобто v1, потрапляючи в гілки патчів та обслуговування для більш ранніх версій програмного забезпечення, тобто v2.

Це призводить до того, що час, витрачений на захист неправильної комісії, або неправильний (можливо, не QAd) код, який досягає і розгортається в неправильній гілці, якщо ми не помічаємо, що код перейшов у неправильну гілку.

Наш дизайн / метод з’єднання та злиття

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

Отже, ми будемо працювати над галуззю розробки випусків, доки не буде визнано , що вона готова , відключимо її для єдиної гілки тестування / UAT / Production, де виконуються всі випуски та обслуговування. Теги використовуються для створення випусків цієї гілки. Поки v1 тестується, для v2 буде створена гілка, і розробники почнуть працювати над новими функціями.

Що, як правило, трапляється в тому, що розробник здійснює роботу, пов'язану з v2-dev гілкою, у v1-dev або v1-prod, або ще гірше, вони об'єднують v2-dev у v1-prod (або подібні подібні помилки).

Ми кажемо більшості розробників не отримувати доступу до гілок -prod , однак код все ще проникає. Група старших розробників «доглядає» за гілкою -prod.

Слід зазначити, що поки v2 тільки починає розробку, все ще може бути кілька досить здоровенних патчів, що надходять у v1 для виправлення неполадок. Тобто v1 може не просто отримати незвичайний невеликий виправлення.

Що ми намагалися поки що

• Маючи окрему гілку -прод, із воротарями. Гілка -prod повинна викликати попередження через своє ім’я, і більшості розробників не потрібно ніколи бути в цій гілці. Це насправді не зменшило проблему.
• Підвищили обізнаність про цю проблему серед розробників, щоб спробувати зробити їх більш пильними. Знову ж таки це було не дуже вдало.

Можливі причини, які я бачу в тому, що розробники переходили на неправильну галузь

• Занадто складна галузева конструкція
• Активно розвиваючись у кількох галузях паралельно. (Проект виявляє симптоми використання лавинної моделі .)
• Розробники не розуміють DVCS досить добре

Прочитані нами питання були дещо актуальними

Я прочитав це запитання про те, що не дотримуюся неправильної гілки, і вважаю, що відповіді щодо візуальних підказок можуть бути корисними. Однак я не зовсім впевнений, що проблеми, з якими ми стикаємось, не є симптомами більш фундаментальної проблеми.

За допомогою візуальних підказок ми можемо легко включити їх до командного рядка, проте приблизно половина команди використовує затемнення, яке я не знаю, як включити візуальні підказки.

Питання

Які методи у вигляді програмного забезпечення, управління проектами чи управління ми можемо використати, щоб зменшити (в ідеалі зупинити) вчинення неправильної гілки, зайнявши наш час або забруднивши розгорнутий код?

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

Проблема полягає в тому, що ви змінюєте те, в чому полягає зміст гілки через процес.

Спочатку v1 devгалузь призначена для розвитку. Усі нові функції переходять туди. В якийсь момент в майбутньому це стає відділом технічного обслуговування для v1 releaseфілії. У цьому суть проблеми.

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

Що вам потрібно зробити, це встановити, яку роль має кожна галузь, і підтримувати її. Якщо роль змінюється, гілка.

Наприклад:

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

У цій моделі розробники завжди зобов’язуються розробляти. Якщо ви будуєте патч, ви перевіряєте патч у гілці цього випуску (а ще краще - розгалужуєте гілку випуску для патча, а потім об'єднуєте її назад у гілку звільнення)

Одна стаття, яку ви повинні прочитати (і, мабуть, заниження "слід") - це розширені стратегії розгалуження SCM від Стивена Венса.

^{У цій роботі я спочатку визначу розгалуження у загальному розумінні. Потім я обговорюю різні стратегії розгалуження, починаючи з очевидних і переходячи до декількох, які більше підходять для більших зусиль з розвитку. Попутно я обговорюю плюси і мінуси кожної стратегії, використовуючи їх для мотивації змін, які складають більш складні стратегії ...}

У цій статті він визначає п’ять ролей, які можуть мати гілки. Іноді гілка може заповнювати дві ролі, а ролі не обов'язково потребують нової гілки , доки політика ролей не зміниться середньою галуззю (ви будете час від часу бачити згадку про "відділення щодо несумісної політики").

Такі ролі:

1. Основна лінія. Тут роблять гілки. Завжди відгалуження від основної лінії полегшує злиття, оскільки дві гілки матимуть спільного предка, який не є гілкою на гілку на гілках.
2. Розвиток. Тут розробники перевіряють код. Можна виділити декілька галузей розвитку, щоб виділити зміни з високим ризиком від тих, що є рутинними та життєвими.
3. Технічне обслуговування. Виправлення помилок у існуючому виробничому середовищі.
4. Накопичення. При злитті двох гілок, можливо, не захочеться ризикувати дестабілізацією основної лінії. Отож, розв’яжіть магістраль, з’єднайте гілки в акумулятор і з’єднайтеся назад до основної лінії, коли речі будуть вирішені.
5. Упаковка. Випуск упаковки відбувається у галузях пакування. Це часто стає випуском і служить для ізоляції випуску зусиль від розвитку. Див. Розділ Як боротися з небажаними зобов'язаннями, які порушують тривалі версії версій? для прикладу, коли упаковка суперечить розвитку.

У вашому прикладі у вас є каскадна основна лінія (це проблема - це робить злиття складніше - що станеться, якщо ви хочете об'єднати виправлення для v1 у v2 і v3?), Розгалуження розробника, що стає гілкою обслуговування ( зміна політики, це проблема).

Гаразд, ви кажете, це чудово, але це було написано для виконання, яке є централізованим VCS - я використовую DVCS.

Давайте подивимося на модель git-flow та побачимо, як вона застосовується.

Основна гілка (синя) - це гілка випуску - для позначення тегів. Це не основна лінія. Основна лінія - це насправді розвивається гілка (жовта). Гілки випуску (зелені) - роль упаковки. Розвиток низького ризику відбувається в основному, розвиток високого ризику відбувається в галузях функції (рожевий). У цій моделі накопичення здійснюється в галузі розвитку. Технічне обслуговування вважається "гарячим виправленням", яке червоного кольору.

Хоча політика ролей не відповідає точному (у кожного продукту є свій дещо інший життєвий цикл), вони є збігом.

Це має спростити вашу політику розгалуження та полегшити її для всіх.

У той час як ви намагалися використовувати окрему гілку -prod з воротарями, це здається, що одне сховище використовується для того, щоб реально наробити виробництво. Якби виробничі нарощування були зроблені лише з сховища виробництва, дозволеного для запису тільки його воротарем, тоді чорти не змогли б підштовхнути його. Це покладає навантаження на воротаря, який би натискав на виробниче репо лише після огляду. Звичайно, люди все-таки зможуть витягнути з виробничого репо, коли потрібно.

Коли люди набувають досвіду, вони повинні повертатися через роль воротаря, щоб отримати глибше розуміння або турботу, якої, здається, їм не вистачає.

І, як правило, застосуйте бритви Occam: вся структура репо повинна бути максимально простою, щоб виконати свою роботу.

Дивіться також коментар Шона.

Цілком можливо, що розробники просто не отримують DVCS досить добре, але я думаю, що набагато ймовірніше, що у вас просто занадто багато відбувається, і дияволи не можуть відслідковувати, що вони роблять з моменту на момент. Вони забувають, в якій галузі вони працюють, і їх зміни закінчуються в неправильному місці.

Я б припустив, що у вас є проблема з тим, що всі працюють у всіх цих галузях регулярно.

Пропозиція @ andy256 щодо окремого сховища для prod неодмінно допоможе, але вам може знадобитися розглянути питання про розбір роботи по-іншому, або, можливо, упорядкування речей, щоб жоден розробник не працював над однією гілкою протягом даного тижня.

Схоже, ви визначили одного з моїх головних ведмедів помилок. Більшість інструментів управління джерелами - це саме те, засоби управління джерелами. Вони дозволяють купі розробників працювати над тим самим вихідним каталогом, вносячи зміни та вирішуючи конфлікти. По дорозі було кілька грубих країв, але це стосується резюме, підривної роботи, git, mercural тощо.

Тоді вам належить наступний крок, коли вам потрібно стабілізувати код для випуску, і ви введете розгалуження. Тут інструменти починають виходити з ладу розробників. Інструменти здатні створити гілку і навіть визначити набори змін, що виникли на гілках після їх розгалуження, але це не проблема, з якою ви стикалися зараз.

Інструменти дійсно погані у виборі, які зміни потрібно скопіювати в інші гілки та коли це має відбутися. Git-stream намагається вирішити це шляхом створення стратегії розгалуження, яка означає, що при об'єднанні гілок всі її зміни об'єднуються, а потім вимагає від програміста зробити розумний вибір щодо того, коли і які гілки об'єднуються.

У єдиному сховищі, де всі розробники працюють над одним проектом, який має нитку єдиного випуску, git flow вирішує проблему, але життя не так просто для багатьох компаній.

Складне середовище - це те, коли у вас є кілька команд, відповідальних за різні аспекти загального рішення, виконуючи внутрішні релізи для інших команд. git-flow просто не здатний вирішити подібне питання.

Єдиний спосіб, коли я бачив цю роботу, - це якщо кожна команда несе відповідальність за визначення своїх випусків та контроль за зміною залежностей. Тільки тому, що команда A випустила реліз 1.3, команда B починає використовувати випуск команди 1.3 лише тоді, коли команда B вибере.

Фактично команда розробників визначає групи змін, які потрібно перемістити, а розробники, які отримують зміни, визначають, коли вони отримують групу змін.

Єдиний інструмент управління джерелом, який я бачив, що справді забезпечує це - acurev - і навіть тоді більшість ваших розробників будуть бурчати про це, оскільки графічний інтерфейс для них занадто заплутаний, і він не веде себе як підривна робота ...