Я пытаюсь решить следующую проблему, с которой мы столкнулись в нашей компании: Мы пытаемся следовать SCRUM. Мы используем модель ветвления, похожую на git-flow. Когда мы сталкиваемся с более крупной историей, которая занимает 2,3 спринта, она не объединяется до тех пор, пока не будут выполнены все подистории. В результате у нас есть длинная ветка, которую трудно слить в конце. Мы начинаем другие истории, основанные на основной ветке, которая совершенно не актуальна из-за большой ветки feature-story. Я предложил по возможности объединить ранние подистории обратно в основную, но руководство сказало, что это слишком рискованно, поскольку изменения могут нарушить развертывание. Как вы справляетесь с длинными историями и ответвлениями?
Идея Scrum состоит в том, чтобы завершать работу спринтами, чтобы вы могли сделать свой прогресс прозрачным. Если у вас есть истории, которые охватывают 2-3 спринта, вы будете скрывать прогресс и делать структуру Scrum менее прозрачной.
Было бы неплохо сосредоточиться на разбивке более крупных историй. Поначалу это может быть проблемой, но это навык, который Scrum-команды должны приобрести, чтобы добиться успеха.
Если вы обнаружите, что вам все еще нужно поддерживать долгоживущие ветки функций, рассмотрите следующий подход:
«Когда мы сталкиваемся с более крупной историей, которая занимает 2,3 спринта» .
Не работайте над этим, исправьте это. Вы должны быть в состоянии объединить историю INVEST . Обратите внимание, что S означает маленький. Сделайте ваши подистории ценными и объединяемыми. Наличие монолитных историй — огромная (но очень распространенная) проблема. Я подозреваю, что ваши подистории напоминают этапы технического проектирования, а не постепенные приращения. Это не совсем так. Люди пишут книги о таких вещах, но я просто дам вам ссылку на очень простую и полезную блок-схему того, как подходить к разделению ваших историй.
«Мы начинаем другие истории, основанные на...» У вас слишком много незавершенной работы (WIP) , и это одна из мелких неприятностей. Улучшайте совместную работу и накапливайте меньше историй.
«но руководство сказало, что это слишком рискованно» .
Во-первых, это может быть связано с вашей проблемой WIP. Когда вы закончите свою историю, состоящую из нескольких спринтов (лучшее слово «эпическая»), всегда есть еще какая-то наполовину сделанная работа в полете. Они не хотят, чтобы все это было в мастере, но решение не в том, чтобы убрать это, а в том, чтобы иметь меньше незавершенного производства.
Во-вторых, истории, которые вы получаете на каждой итерации, должны быть выполнены (разработка, контроль качества в тестовых средах и т. д.), используя навыки внутри вашей команды. Вам нужно выпускать каждую итерацию, в этом суть. Это то, как вы приносите пользу и быстро получаете обратную связь от клиентов. Вы должны сопротивляться этому. Но вы также должны убедиться, что у вас высокие стандарты качества (т. е. много автоматизации тестирования), чтобы люди не чувствовали, что использование вашего кода связано с большим риском.
TLDR Решение не хитрое управление ветками, и git вас не спасет. Разделите свои истории и узнайте, чего можно достичь с помощью итераций. Или, я полагаю, бюджет на ужасные слияния.
Мы используем технику переключения функций ([переключение функций Википедии]: https://en.wikipedia.org/wiki/Feature_toggle ), и до сих пор мы были очень эффективны в том, чтобы своевременно доставлять, изящно обрабатывать большие функции и отключать функции . которые не сделаны к дате выпуска.
Переключение функций (также переключатель функций, флаг функций, переключатель функций, условная функция и т. д.) — это метод разработки программного обеспечения, который пытается предоставить альтернативу поддержке нескольких ветвей исходного кода (известных как ветви функций).
Непрерывный выпуск и непрерывное развертывание обеспечивают разработчикам быструю обратную связь об их написании кода. Это требует интеграции изменений их кода как можно раньше. Ветки функций вводят обход этого процесса. Переключатели функций возвращают разработчиков в нужное русло, но пути выполнения их функций по-прежнему «мертвы», если переключатель «выключен». Но для того, чтобы включить новые пути выполнения, достаточно просто установить переключатель в положение «включено».
Этот метод позволяет разработчикам выпускать версию продукта с незавершенными функциями. Эти незавершенные функции скрыты (переключены), поэтому они не отображаются в пользовательском интерфейсе. Это позволяет доставлять множество небольших добавочных версий программного обеспечения без затрат на постоянное ветвление и слияние.
Еще одним преимуществом функциональных флагов являются канареечные запуски. Канареечное развертывание (также известное как канареечное развертывание или канареечный выпуск) представляет собой развертывание функций для небольшого числа пользователей, чтобы оценить реакцию всей системы. Запуск канареек позволяет медленно развертывать функцию и измерять реакцию реальных пользователей-«канареек», выискивая ранние признаки опасности. Если функция не подходит, ее можно откатить. Запуск Canary — это передовая практика для организаций гибкой разработки, практикующих непрерывную поставку, чтобы двигаться быстрее.
Мы определяем поставляемую функцию как MVP минимально жизнеспособного продукта, который обычно переводится как эпик, который может распространяться на множество спринтов или в рамках спринта (наш спринт длится неделю), эпик будет разбит на несколько пользовательских историй INVEST, высокий уровень и клиентоориентированность. Любые готовые пользовательские истории ежедневно объединяются в основную ветку.
Другие обращали внимание на тот факт, что ваши истории слишком велики, но если вы разобьете их ( а вы должны это сделать), вы сделаете истории, которые могут быть не совсем готовы к «прайм-тайму». Вы не хотите развертывать эти наполовину готовые функции, как и ваш отдел маркетинга.
Но вот секрет...
Вы хотите их развернуть. Это ваш отдел маркетинга не хочет. И вы оба правы .
Маркетинг не хочет, чтобы наполовину готовые функции отправлялись в производство, но вы хотите объединить эти изменения и развернуть, чтобы это было проще. Таким образом, вы делаете оба.
Напишите переключатель функций для этих давно разрабатываемых функций. Объединяйте свои истории, когда они будут готовы, как и любую другую историю. Теперь, в целях тестирования/демонстрации, вы включаете эту функцию, но отключаете ее для производства . Это позволяет вам часто объединять, отправлять функцию вашему QA и владельцу продукта для быстрой обратной связи, но оставлять ее «неотправленной» для ваших конечных пользователей.
Как это сделать, можно легко заполнить серию сообщений в блоге, поэтому я оставлю вам дальнейшее исследование переключателей функций.
Смешные рассуждения, ваше руководство. Раннее слияние ветки рискует нарушить развертывание, поэтому лучше добавить в эту ветку больше кода перед ее слиянием. Как именно, скажите на милость, добавление многонедельного кода снижает риск нарушения развертывания?
Автоматизируйте развертывание и часто выполняйте развертывание в тестовой среде. Стремитесь к ежедневному, но чаще, если можете. Таким образом, ваше «сломанное развертывание» всегда вызвано несколькими строками кода, которые вы только что написали. Легко исправить.
У вашего руководства есть чувство юмора.
Слияние устаревшей ветки с master будет проще, если вы создадите новую структуру каталогов для новой функции, а затем выполните интерактивное слияние, а не автоматическое слияние:
Написание встроенных утверждений очень помогает для больших историй. Проверяйте код утверждений и создавайте отчет о тестировании в конце каждого спринта, чтобы показать прогресс. Это позволяет избежать необходимости:
использованная литература
Тодд А. Джейкобс
Юэн
Педро