Comments 14
Сложно как то. Получается архитектура софта такая, потому, что контроль версий такой. И контроль версиями без Спрингс сильно усложняется, так как придется городить фичофлаги, придумывать механизм управления компонентами. И так далее.
Короче сплошные зависимости. Ещё и в коде будут кучи проверок, активна фича или нет, причем нет гарантии, что где то такую проверку не забыли вставить и вообще все равно придется менять стабильный код, встраивая ветвление. Где гарантия, что не напартачили? Значит усложняется тестирование, старого и нового кода перед релизом. Клиенты будут рады.
Да ещё требование, что бы комитты были небольшими. Такого не бывает, если только баги какие то. Для чего то большего все равно придется бранчи создавать и вот мы мы тут снова.
Здравствуйте.
Все сложно когда в первый раз.
Архитектура такая из-за современных требований, например по проведению A/B тестирование. Методология ветвления просто подстроилась под новые требования и новую архитектуру.
Без спринг обойтись можно, а вот без инверсии зависимостей наверное нет, но не спринг один предоставляет CDI контейнер.
Гарантий кроме вас самих вам ни кто не даст, делайте код ревью пишите тесты.
Возможность создания небольших коммитов и достигается за счёт поэтапного создания нового функционала, т.е. вы закидываете в транк тот код который ещё не до конца доделан, но он ни чего не ломает.
Не скажу, что приведённый автором пример мне очень пришёлся по душе. Мы используем TBD и feature flags, которые контролируются в рантайме посредством LaunchDarkly. Но feature флаг — это всегда кратковременное явление. В идеале их количество должно быть нулевым!
Зато соглашусь насчёт TBD. Там, где от коммита до релиза в dev, staging и production — один цикл CI, нет никакого смысла разветвлять код, чтобы попилить фичу. Добавляется флаг, фича пишется и деплоится во все среды и её сразу же можно протестировать на заданной группе пользователей.
В чём профит? — Код един во времени и пространстве. Пропадают ситуации когда "мы замёрджили и всё сломалось". Нет багфиксовых веток. Нет специальных деплоев для разных клиентов. Каждый разработчик сделав "git pull" получает код в том же состоянии, в каком он находится на боевых серверах.
И самый кайф — решаются проблемы с рефакторингом! Переименовали класс? — коммит и деплой. Переделали сигнатуру метода? — коммит и деплой. И всё это — маленькие, понятные коммиты, за которыми легко следовать.
И самый кайф — решаются проблемы с рефакторингом! Переименовали класс? — коммит и деплой. Переделали сигнатуру метода? — коммит и деплой.
И как это работает в команде из больше чем одного человека?
Ты "поменял и задеплоил" и я тоже самое, ну чуток под другому, поменял и задеплоил. Оба тратим время на одно и тоже. И самое главное, каждую минуту надо пулить код, а то мало ли кто-то уже это всё поправил и сделал… Или не тоже самое сделал, но код теперь в таком состоянии, что твой коммит теряет смысл. Или придётся тратить кучу времени на коммуникации "Посоны, не трогайте класс FooBoo, я его сейчас менять буду", отвлекая команду.
Опять же постоянные "ревью на 10 мин" просто не дадут тебе нормально работать над своей задачей. Когда тебе постоянно надо чужие ревью смотреть как сосредоточиться на совей задаче?
Читал много по этой теме, доклады видел, но абсолютно все примеры максимально примитивны. На примитивщине любой подход будет работать. А как это будет жить когда хотя бы 10, 15 разработчиков одновременно меняют код? А если проекту при этом еще не 100 лет и изменения не точечные для багфикса?
В общем не могу понять, как это в принципе может работать) Тут и в обычном режиме, в команде из 10 человек, рефакторинг частенько проблематично вести, приходится его планово делать, а уж в таком хаосе КПД должно падать просто катастрофически...
Разберу как и почему это работает у нас.
В нашей команде 5 человек. Мы пилим бэкенд. Мы девопсы и отвечаем за всю цепочку, благо AWS, infrastructure-as-code и приложения в контейнерах.
Мы сидим в одной комнате площадью ~ 30m^2 и с коммуникацией нет никаких проблем. Более того, мы большие любители посидеть за одним столом вместе, обычно вдвоём, втроём, даже всей командой.
TDD особенно легко даётся когда работаешь в паре. Всевозможные линтеры локально и в CI-пайплайне отметают замечания в стиле "ты тут пропустил пробел". И благодаря всему этому число код-ревью сведено к минимуму. От формальных ревью мы уже давно отказались. Обычно это сообщение в Slack "ребята, мы тут запилили <что-то>, гляньте пожалуйста <ссылка на commits diff в Gitlab>".
О, у нас есть ветки. Но они в большинстве своём — для экспериментов и редко напрямую сливаются в master. И живут эти ветки, самое большее — пару дней.
И ещё важные столпы нашего процесса — чистая архитектура, микросервисы и формализованное общение между ними (с помощью инструментария pact.io).
Мы отказались от спринта и релизов раз в Х недель. Коммит-пуш-CI-деплой — Continuous Delivery. Если билд сломан и сломан серьёзно, то все остальные дела откладываются — смысл работать над фичей, если билд сломан? Если обнаруживается баг, то разработка чего-то нового приостанавливается в принципе — смысл пилить фичу, если в коде ошибка и она ведёт к проблемам у клиента, соответственно — к потере НАШЕЙ репутации? И как вы понимаете, багфикс выходит не через две недели, а через 10-15 минут, после того как код был залит в репозиторий.
Для нас TBD — это способ сократить время обратной связи (feedback loop). Он не дался нам легко и сразу. Мы набили много шишек и успели обрасти различными ритуалами. Например если сломался билд, то разработчик сломавший билд отписывается в комментарии (к автоматическому оповещению на специальном канале в Slackе), почему сломался билд и что он собирается с этим делать.
Нормой считается заявить во всеуслышание о том, чем собираешься заняться дальше и поинтересоваться мнением коллег на эту тему. TBD стал ответом на вызовы Continuous Delivery. И как я писал выше, мы стараемся свести количество Feature-флагов к минимуму и выкидывать их при первой же возможности.
Может когда проекту будет 100-человеко-лет и в команде будет 10-15 разработчиков, нам придётся изменить подход. Но пока всё работает и мы, а главное — наши клиенты, очень довольны :)
Если все скопом набросились на одну проблему в одном и том же месте, то либо распределение задач и коммуникация хромают, либо людей на проект многовато. Обычно все ровно наоборот, задач и кода намного больше чем разработчиков. Какое там пересекаться в изменениях кода, максимум git pull с fast-forward перед своим коммитом и все.
Если вы внимательно прочитаете изначальное сообщение, то речь там идёт про рефакторинг.
У нас вот например рефакторинг это часть процесса разработки. Не особо большие рефакторинги делаются "по ходу дела", во время работы над задачей.
А так как задачи идут по плану, то крайне редко люди пересекаются во время рефакторинга.
Большой рефакторинг это отдельная задача, про которую все в команде вкурсе.
И которую видно в джире, с описанием того, что там будет изменяться.
Все просто и процесс прозрачен и понятен любому участнику.
Какое там пересекаться в изменениях кода
Возможно вы всегда работаете в проектах на миллионы строк и всегда пилите разные участки. В обычных же проектах пересечься очень просто.
Банальный пример. У вас задача добавить одно поле в модельку для какой-то бизнес функции. У вашего коллеги своя бизнес функция, но тоже надо добавить поле в модельку. И понеслась) это поле участвует в куче мест (печати, экспорты, выгрузки, валидации, подписи и т.д. и т.п.), и вот уже одним полем в модельке затронуто 100500 классов включая какие-то общие интерфейсы… Это так, на вскидку, в реале вариантов очень много)
Здравствуйте! Вы не поверите, но TBD у нас работает именно под микросервисную архитектуру, с приложениями от 300 до 1500 строк.
Хорошо, внесли вы новое поле в модельку. Это что-то сломало?
Если нет, пушим.
Добавили обработку поля в одном из классов. Это сломало поведение этого класса или других классов?
Если нет, пушим.
Нужно внести поле в интерфейс. Создали новый default метод в интерфейсе с этим полем. Это сломало классы где используется интерфейс?
Если нет, пушим.
Реализовали новый метод, поставили фичер флаг в классе клиенте по которому выбираем между старым методом и новым. Это сломало поведение данного класса?
Если нет, пушим.
Я думаю можно не продолжать.
Плюс, то, что вы описали это вовсе не проблема методологии ветвления, а проблема связанная с нарушением OCP.
Зависит от опредлейина слово "Комманда".
Если комманда это когда люди вместе что-то делают, говорят с друг другом (не через JIRA) имеют одинаковые цели (в спринте например), интересуются чужим контекстом и делятся своим — то нет проблем.
По моему опыту это скалируется до 3-5 человек в таком сетапе. Выше наверно сложнее — но комманда больше 5 человек девелоперов для меня уже не команда а более сложная и разрозненная группа- хотя её и будут обызвать коммандой. В группе болле 5-7 человек естественным образом получаются новы структуры и деления — контекст и цели начинают терятся… Процессы услознаются и формализируются…
Так что на практике обычно макс. 3 человека копают рядом (дефакто комманда).
Фичи не должны лежать месяцами а в идеале умещятся в разумные рамки (длинна спинта).
Если у вас одновреммено фичетоглинг на 10 фичь — это не правильно… У нас обычно не боллее 1 на сервис. Ах да и каждый сервис это отдельная репа. Сервисы слабо связаны.
Остальное потватывают тесты и CI/CD.
Trunk Based Development и Spring Boot, или ветвись оно все по абстракции