Скорость изменения определить можно по длительности цикла Бойда.

А там две ключевых фазы это сбор данных наблюдения и их анализ.

Ну так то актуальную. А не предельно возможную.

А если построить кривую на основании истории, можно классику с-образной кривой там найти)

Ну и соответственно прикинуть в какой точке относительно общей протяженности этой кривой мы находимся.

Там же вторая производная нужна.

@dphil простите, что возвращаюсь к старой теме, но все выходные думал и не мог заснуть. Можете рассказать как у вас в монорепе усроен CI? Он собирает все компоненты монорепы при каждом коммите? Работает ли версионирование при помощи тегов? Если нужно выпустить релиз одного из компонентов, то все остальные тоже получают новую версию?

У меня в последних проектах общая специфика - относительно редкие релизы (два-три раза в неделю, а иногда и реже).
Сборка - большой gradle-скрипт, которые собирает все компоненты из бранча и прогоняет тесты (выкладывая на тестовый стенд, понятное дело). Это происходит на каждый коммит (и еще и у разработчика на машине).
Версии у всех модулей свои, поднимаются при разработке в бранче руками (иногда разработчики забывали, но редко).
Для ускорения сборки те модули, что в бранче не изменились - подтягиваются из репозитария.
Релиз всей системы помечается тегом, список версий модулей строится автоматом, но к релизу пишутся ручные инструкции по выкладке (если там что-то более сложное, нежели обновить сервисы по стандартной схеме).
Релиз - у всей системы (тег общий), но можно сделать релиз, в котором поменялся только один компонент.

Это - далеко не идеальная схема для относительно небольшой команды (до 20 человек) без особых ресурсов на devops активности.
Можно сделать гораздо лучше, но зависит от требований и имеющихся ресурсов.

Сейчас у нас еще и несколько разных решений для разных клиентов собираются вместе (с генерацией независимых ансибл-скриптов), но тут процессы еще развиваются, я про них расскажу, когда дойдем до удачной точки (вообще, выпуск решений для 5-50 клиентов - очень интересная задача)

Спасибо за подробный ответ, буду ждать продолжения.

Ну, это не скоро...

странновато! вроде бы именно отсутствие необходимости версионировать модули - чуть ли не главный selling point для монореп

а так это больше напоминает подход "просто сложили всё что было в одну кучку" 😂

Ну, у меня главный пойнт - общая схема бранчей.

А в чем выигрыш от общей схемы бранчей? Много изменений которые затрагивают более одного компонента?

Ну, фича обычно затрагивает и фронт и гейт и бэк

а вот отсутствие бранчей - это второй по популярности selling point для монореп 🙂

отсутствие бренчей - это плюс, чтоб не мучиться с последующим merge, верно?

Монорепа с общей версией и без бранчей? я бы такое не купил

т.е. это по факту, возврат от распределённого SCM к централизованному, когда кто-то блокирует файл, а другой его не может менять. чтоб тоже с merge не мучиться.