Комментарии 21
Итак, я не буду завозить в команду TBD если:
Команда 1-3 человека и расширение не планируется. Для такого размера команды TBD довольно сложный инструмент.
И прямо тут же практически написано, что всего было 5 команд общей численностью 20 человек (т.е. в среднем - четыре). То есть, 3 это слишком мало, а 4 в самый раз? Ну хм.
Здравствуйте! Благодарю вас за комментарий.
Размер команды это не единственный параметр для выбора в пользу TBD. У меня в одной из команд было 2 человека, но там была очень активная разработка с большим числом merge conflicts и потребностью в постоянной синхронизации кода между разработчиками. TBD решил эту проблему.
В другой команде было 3 человека, но там все итак хорошо работало, поэтому смысла завозить TBD не было.
Поэтому важно смотреть не только на какой-то один параметр, но и на все параметры в совокупности.
Как по мне, вы по сути подтвердили мои сомнения. 1-3 много, 4 в самый раз, а 2 это плохо. И? Выходит этот параметр вообще не важен (на самом деле важен конечно, потому что у 1 человека конфликты при слиянии веток очевидно очень редки (хотя я не просто могу их представить, а лично видел). В итоге просто число человек в команде без других показателей вообще не говорит ни о чем.
Ну и потом - если у вас большое число конфликтов у двух людей, значит они почему-то правят одни и те же куски кода? Это наводит на мысли, что на самом деле этот код просто обладает излишней связностью, и его бы надо порефакторить, разбив на более независимые куски. Т.е. качество кода, что бы мы под этим не понимали, чуть ли не более важно при выборе методов работы с ветками в репозитории.
В итоге просто число человек в команде без других показателей вообще не говорит ни о чем.
Возможно, я не совсем корректно указал в статье, что на выбор TBD влияет не только отдельные параметры, но и параметры в совокупности. Судя по вашему комментарию, для вас это важно. Спасибо за вашу внимательность, вы помогли мне сделать статью лучше, я оставлю update в статье.
Ну и потом - если у вас большое число конфликтов у двух людей, значит они почему-то правят одни и те же куски кода? Это наводит на мысли, что на самом деле этот код просто обладает излишней связностью, и его бы надо порефакторить, разбив на более независимые куски.
Ситуация про связность кода, которую вы описали, определенно имеет место быть, но она не единственная. В моей практике не раз был случай, когда для бизнеса было важно сделать несколько фич в одном модуле за короткий срок. В таком случае, ваша команда либо часто синхронизируется, как предлагает TBD, либо получаете много merge конфликтов при слиянии нескольких веток, в каждой из которых по несколько дней работы разработчика.
Т.е. качество кода, что бы мы под этим не понимали, чуть ли не более важно при выборе методов работы с ветками в репозитории.
Я с вами согласен, и хотел бы заметить, что в своей статье я как раз упоминаю атомарные коммиты, линтеры, статические анализаторы кода, написание тестов, и другие best practices для разработки качественного кода. TBD, скорее, является набором практик по написанию и доставке качественного кода - интересным и удобным, но, безусловно, не единственным.
Несколько команд общей численностью в 25 разработчиков, слезли с TBD с большим удовольствием, потому что это вообще всегда нерабочая мастер ветка. Гораздо удобнее сделать полную фичу в долгой или очень долгой ветке, чем обкладывать весь код фича-ифами, которые все равно рискуют выстрелить в проде.
Здравствуйте! Благодарю вас за комментарий.
это вообще всегда нерабочая мастер ветка
При правильно приготовленном TBD такого быть не должно. Возможно, вы не покрываете код тестами, или не соблюдаете атомарность в написании кода, или не делаете должным образом code review, или сразу не исправляете сломанный trunk - причин может быть множество. Будет здорово если вы побольше расскажете про контекст.
Гораздо удобнее сделать полную фичу в долгой или очень долгой ветке
А есть ли у вас конфликты при слиянии кода, которые требуют много времени на исправление? Есть ли случаи, когда разработчики дублируют свою работу по исправлению багов, потому что каждый работает в своей ветке по нескольку дней?
Посыл моей статьи в том, что сначала нужно проанализировать нужен ли вам TBD в принципе. Если вы решили что нужен, а потом попробовали и поняли что не нужен или неудобен - отказаться от него это тоже хорошее решение.
Всё держится на безусловной вере в непогрешимость разработчика, что он не ошибается, а если даже и ошибается, то уже точно не в юнит-тестах, ведь в них нет и не может быть ошибок, и покрытие 100%. И это не просто красивый процент, а прям на каждую строку несколько строк тестов. И применение тогл фич всегда чёткое и безошибочное.
Зачем вообще бранчеваться? Почему бы с такими вводными и такими железобетонными UT/FT не отправлять изменения сразу в прод? И зачем тут QA? Это ведь подрывает доверие к разработке.
А если честно, и правда больше нечем заняться, как выдумывать и навязывать совершенно не гибкий подход к разработке? Не удивлюсь, если увижу в продаже книгу "TBD в действии", 100500 выступлений, митапов, вебинаров на эту тему.
Git очень гибкая, надёжная и удобная система. Почему бы не создавать столько веток сколько нужно в каждом конкретном случае, и даже на отрезке времени. Тот же самый git-flow, в полной мере наверное редко когда используется, но он удобен для управления процессом, и кастомизируется как угодно.
Зачем эти огороды городить? Может лучше сосредоточиться на разработке?
По описанию выглядит как обычный GitLab flow, ну может за исключением пункта "Коммиты прямо в trunk". Делаем ветку для задачи, код-ревью и мерж. Можете описать, в чем отличия вашего подхода?
Здравствуйте! Благодарю вас за комментарий.
Сразу хотел бы обозначить, что это не мой подход, он был придуман Paul Hammant в 2017 году. Точнее, он собрал ряд хороших практик в разработке ПО и запаковал их в коробку, которую назвал TBD.
Если кратко, то GitFlow/Gitlab Flow/Github Flow это системы ветвления, а TBD это больше про культуру работы, система ветвления это только часть TBD.
Если подробно, то вот отличия:
В GitLab Flow нет техники branch by abstraction.
В GitLab Flow могут быть feature ветки с долгим временем жизни, в TBD такое не поощряется - feature веток в классическом понимании там нет, работаем как можно более атомарно, хорошим тоном считается вливание своего кода в общую ветку разработки 1 раз в рабочий день.
В GitLab Flow есть pre-production и production ветки. В TBD функцию pre-production веток выполняют release ветки, но они опциональны, в ряде случаев вы можете собирать релиз прямо из trunk. Тут я вижу отличие больше в названии веток. Production веток в GitLab Flow нет.
CI/CD входит в TBD, а вот в GitLab Flow напрямую этого нет. Скорее, в работе вы делаете связку GitLab Flow + CI/CD.
Написание тестов это часть TBD, без них тяжело поддерживать trunk в рабочем состоянии. В GitLab Flow напрямую этого нет.
Сразу оговорюсь, что я не работал с GitLab Flow/Github Flow, поэтому допускаю что мой ответ может быть некорректен в некоторых местах. Информацию для ответа я взял из этой статьи - там же приведено сравнение всех систем ветвления.
С долгими ветками надо работать не так, как с короткими. Долгая ветка становится главной для фичи, и работать с ней надо так же, как с main/master. Ветки для подзадач делаются от этой ветки, при мерже подзадачи в ветку делается код-ревью. 1-2 раза в неделю в нее мержится main. Тогда не будет больших конфликтов при мерже ее в main, и не надо будет выкладывать на прод недоделанную функциональность и защищать ее фиче-флагами.
Да, так тоже можно. Но на практике, когда мы работали по git flow, я столкнулся со следующей ситуацией. У нас был модуль комментариев, мы отвели ветку и начали делать там новые фичи и доработки. В это время на продакшене находят баг в комментариях, продакт приходит к разработчику, который не работает над комментариями, тот быстро исправляет это в hotfix ветке, выкатывает релиз, hotfix вливает в master. Затем master был влит в ветку комментариев и исправление бага затерлось. Поэтому в следующем релизе на продакшене оказался тот же самый баг.
Проблему, которую я описал, можно исправить несколькими способами. В TBD это исправляется частым вливанием кода в общую ветку разработки. В вашем случае это либо жесткий контроль со стороны тимлида за входящими задачами, либо прокачкой коммуникации внутри команды, наверняка есть еще способы.
Моя статья, скорее, написана для тех, кто уже изучил TBD и хочет попробовать, но столкнулся с какими-то трудностями. Если вас устраивает ваш GitLab Flow и вы не видите причин его менять - не меняйте, оставайтесь на нем.
Если что, Git Flow и GitLab Flow это не одно и то же, GitLab Flow проще.
тот быстро исправляет это в hotfix ветке
С GitLab Flow исправления обычно мержат сразу в master. Иногда делают hotfix ветку, но это для редких случаев, когда в master уже есть что-то, что пока нежелательно выкладывать.
Затем master был влит в ветку комментариев и исправление бага затерлось.
Это какая-то очень странная ситуация. Видимо конфликты разрешили неправильно. Но это могло случиться и с TBD.
Видимо конфликты разрешили неправильно. Но это могло случиться и с TBD.
В TBD очень частая синхронизация и атомарные изменения в коде, поэтому чтобы такая ситуация произошла в TBD надо очень постараться. В системах ветвления, которая основана на долгоживущих feature ветках, я такие ситуации вижу регулярно, особенно в активной продуктовой разработке.
Что-то основанное на заведомо необходимых черрипиках выглядит плохо. Вообще малой командой можно очень извращенно приседать, вплоть до хранения веток задач порознь до момента релиза который оформляется как кандидат и отправки в девелоп и мастер исключительно его. Все очень зависит от релиз трейна. В мобайле с малыми командами, долгим тестированием и согласованием состава релиза лучше потом много мержить чем постоянно черрипикать. Можно нехило так влететь с ними в сложно диагностируемую неконсистентность.
Здравствуйте! Благодарю вас за комментарий.
Что-то основанное на заведомо необходимых черрипиках выглядит плохо.
У каждого инструмента есть свои границы применимости и случаи применения. В случае с TBD cherry-pick применяется только в одной ситуации, причину я также расписал. Если вы делаете по-другому - без проблем, это ваше право.
В мобайле с малыми командами, долгим тестированием и согласованием состава релиза лучше потом много мержить чем постоянно черрипикать
Речь не идет про постоянные черрипики, там всего одна ситуация при релизе, в разработке черрипики вообще не применяются.
Моя статья, скорее, написана для тех, кто уже изучил TBD и хочет попробовать, но столкнулся с какими-то трудностями. Если вас устраивает ваш рабочий процесс и вы не видите причин его менять - не меняйте, оставайтесь на нем.
Да это понятно. Просто подливаю ложку дегтя. Или добавляю акцент. Во внедрении инструментов ключевой же вопрос: "Чтобы что?". Архитектуры, аджайл-практики, различные driven development, воркфлоу, гитфлоу - всегда вяжутся на кадры, особенности продукта, структуру организации, стеки и прочее, в том числе и друг на друга. Этот момент постоянно ускользает из внимания многих даже опытных людей, не то что неофитов.
Скажем даже гитлаб-флоу уже доставляет неудобств при релизах по расписанию. Потому как состав его частенько утверждается после тестирования отдельно по задачам из билдов ci по результатам регресса кандидата с уточнением. И если по итогам всего решили какую-то довольно комплексную задачу не катить, то возникает необходимость хирургического вмешательство в девелоп. А сроки-то первичны. Усугублять это картину еще и тбд нет абсолютно никакого смысла, если оставлять воркфлоу над этим таким же.
Поэтому закрываю форточку и душню что первичен не подход а контекст внедрения.
Поэтому закрываю форточку и душню что первичен не подход а контекст внедрения.
Ровно с этого и началась моя статья. Вот выдержка из второго абзаца статьи:
Чтобы эффективно применить инструмент, нужно понять что он делает и где может быть полезен.
Я даже сделал отдельный небольшой раздел под названием "Нужен ли вам TBD?".
В любом случае - спасибо за ваше мнение!
Мой опыт перевода команд разработки на trunk-based development