Size: a a a

Архитектура ИТ-решений

2020 August 24

AL

Alexander Luchkov in Архитектура ИТ-решений
Скорость изменения определить можно по длительности цикла Бойда.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
А там две ключевых фазы это сбор данных наблюдения и их анализ.
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Ну так то актуальную. А не предельно возможную.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
А если построить кривую на основании истории, можно классику с-образной кривой там найти)
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Ну и соответственно прикинуть в какой точке относительно общей протяженности этой кривой мы находимся.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Там же вторая производная нужна.
источник

П

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

PD

Phil Delgyado in Архитектура ИТ-решений
ПашМиш
@dphil простите, что возвращаюсь к старой теме, но все выходные думал и не мог заснуть. Можете рассказать как у вас в монорепе усроен CI? Он собирает все компоненты монорепы при каждом коммите? Работает ли версионирование при помощи тегов? Если нужно выпустить релиз одного из компонентов, то все остальные тоже получают новую версию?
У меня в последних проектах общая специфика - относительно редкие релизы (два-три раза в неделю, а иногда и реже).
Сборка - большой gradle-скрипт, которые собирает все компоненты из бранча и прогоняет тесты (выкладывая на тестовый стенд, понятное дело). Это происходит на каждый коммит (и еще и у разработчика на машине).
Версии у всех модулей свои, поднимаются при разработке в бранче руками (иногда разработчики забывали, но редко).
Для ускорения сборки те модули, что в бранче не изменились - подтягиваются из репозитария.
Релиз всей системы помечается тегом, список версий модулей строится автоматом, но к релизу пишутся ручные инструкции по выкладке (если там что-то более сложное, нежели обновить сервисы по стандартной схеме).
Релиз - у всей системы (тег общий), но можно сделать релиз, в котором поменялся только один компонент.

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

PD

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

П

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

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, это не скоро...
источник

OS

Oleg Soroka in Архитектура ИТ-решений
странновато! вроде бы именно отсутствие необходимости версионировать модули - чуть ли не главный selling point для монореп
источник

OS

Oleg Soroka in Архитектура ИТ-решений
а так это больше напоминает подход "просто сложили всё что было в одну кучку" 😂
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, у меня главный пойнт - общая схема бранчей.
источник

П

ПашМиш in Архитектура ИТ-решений
Phil Delgyado
Ну, у меня главный пойнт - общая схема бранчей.
А в чем выигрыш от общей схемы бранчей? Много изменений которые затрагивают более одного компонента?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, фича обычно затрагивает и фронт и гейт и бэк
источник

OS

Oleg Soroka in Архитектура ИТ-решений
а вот отсутствие бранчей - это второй по популярности selling point для монореп 🙂
источник

IP

Igor Petetskikh in Архитектура ИТ-решений
отсутствие бренчей - это плюс, чтоб не мучиться с последующим merge, верно?
источник

П

ПашМиш in Архитектура ИТ-решений
Oleg Soroka
а вот отсутствие бранчей - это второй по популярности selling point для монореп 🙂
Монорепа с общей версией и без бранчей? я бы такое не купил
источник

IP

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