Малый размер инкремента, проходящего весь путь от замысла до выпуска и максимальная независимость разработки инкрементов друг от друга (обеспечивается архитектурно). Часть этого тренда — параллельная инженерия.
Название тренда: выпуск фичей (feature это минимальный инкремент)
Как проявляется?
Ох. Домен наш кадро-бухгалтерский разбит на поддомены. Сейчас я думаю, что это архитектурное разбиение скорее по бизнес возможностям, нежели по bounded context. И тут сразу есть нюансы. Архитектурное разбиение всегда идёт в двух плоскостях: это оргархитектура и архитектура системы. Архитектура системы (софта нашего) сделана так, что у нас пачка сервисов. Деление на сервисы именно так, как оно сделано сейчас, это результат на половину спонтанных, на половину сознательных решений многих людей. Среди этих людей разработчики из первых поколений, делавшие систему, дальше может какие-то лиды и архитектор (предыдущий, нынешний на ним донашивает наследие) со своим видением. Причём многие из решений принимаются не из бизнес соображений, есть чисто технические (что-то сервис стал тормозить, давайте вот этот кусок от него отделим в отдельный сервис), есть технические или бывали технические бравады (давайте с одного языка перепишем на другой, потому что у нас тут вроде людей больше в команде). Итого мы имеем условно микросервисную архитектуру, каждый сервис можно разрабатывать и деплоить отдельно. Именно деплоить, с деливери всё сложнее.
Организационно раньше были команды, которые отвечают за сервис или за пачку сервисов. Сейчас команды разделены как кроссфункциональные команды с привязкой с бизнес возможности (Лимиты, Налоги, Удержания и т.п.). Кроссфункциональная команда подразумевает, что в ней есть все нужные люди, чтобы выпустить фичу.
На уровне выпуска кода фичей у нас используется Feature branch, причём я была уверена до вчерашнего дня, что у нас есть Continuous Integration. Continuous Delivery нет, потому что сразу на продакшен ничего не катится. Но хотя бы непрерывная интеграция вполне себе. У нас своеобразная модификация GitFlow c длинным релизным циклом и четырёхуровневой системой стендов: review стенд проверка конкретной фичи из ветки, dev стенд слияние фичей по мере готовности, на препрод живёт либо прошлый релиз, либо новый релиз-кандидат (живёт пока проходит регресс тестирование, потом катится на прод), собственно прод (на прод штантно заезжает очередной релиз и могут внепланого доливаться хотфиксы). Хотфиксы идут всё равно через все стенды. Подробнее про какие ещё бывают варианты ветвления и слияния. Забавно с CI, путаница всюду. Во-первых, всегда пишут в связке CI/CD, зайдите в любую вакансию разработчиков, там будет среди умений именно эта связка. Сами разработчики тоже молодцы, в резюме могут писать “настраивал CI/CD на проекте”. Я такое не пишу, но скорее всего могла бы сказать делала вот такие штуки для CI. На каждом проекте, то линтеры добавляю в пайплайн, то со скоростью запуска тестов бьёмся. Но получается общепринятое понимание CI это непрерывная проверка кода на работоспособность (и какие там у вас ещё встроены проверки в пайплайн). Но это код внутри ветки. Эта проверка запускается на каждое запушенное изменение кода, при этом этот код никуда не попадает непосредственно до слияния веток. Какая-то мутная разница в описании GithubFlow и Trunk based development. Как будто нового в trunk только feature flags. Т.е. мы можем доделывать до конца фичу и тут же её сливать и выкатывать, а можем не до конца. Понятно, что частота выкатки тут будет в разы отличаться. Но раз не доделываем, то прячем от пользователей за фича флагами/тогглами/переключателями.
Что вы планируете в связи с этим предпринять
Я думаю из описания понятно, что воплощению малого размера инкремента мешают проблемы на всех уровнях. Нужно переделывать релизный цикл. Оговорка с быстрой доставкой звучит так “в основную ветку попадает только работоспособный код”. А это вопрос качества проверок качества) И автоматизации проверок. И CI внутри сервиса не гарантирует никаким образом, что фича (которая затрагивает несколько сервисов) будет работать как ожидалось. Может и ладно, что не будет? Если её можно выключить в любой момент. Хотя конечно мы понимаем, что не всё можно выключить. Например, если изменения в БД накатились, их никто ревертить не будет. Изменения кода можно откатить. Но опять же если вливание фичи размазано, то откатить можно только последний кусочек. Теги с версией на каждый коммит (инкремент)? С тестированием тоже прикольно, если коммиты небольшие и льются постоянно, взаимовлияние изменений не отследить как будто. Т.е. как будто мы двигаемся всегда вперёд, сломали или не завелось, окей, вливайте следующее. Плотность изменений же большая, выяснить причинно-следственные связи как-то маловероятно. Хотя наверное и сейчас уже тоже сложно понять, что на что повляет…
По классике ещё вопрос: а промежуточные версии бывают? Я вижу опять два варианта запрыгивания в TBD: 1) надо сначала найти/описать все проблемы из которых мы не можем просто взять и начать так работать, и предварительно их до какого-то уровня порешать, а потом прыгать 2) проблемы всё равно ищем, фиксим, но делаем какой-то промежуточный вариант, где релизы почаще, ветки по меньше, фича флаги появились хотя бы, но всё-таки расписание и менеджмент не падает в обморок…
Надо думать дальше.