DT
проблема обычно в том, что так бывает только когда команда заранее решила выбрать модель разработки “монолит” и заранее делает подготовку к тому, чтобы это был development at scale
Size: a a a
2021 September 29
DT
Miro, в основном Java
DT
На самом деле не так плохо, релизимся каждый день, багов в прод почти не уходит, релизы пропускаем редко. Но поцессных усилий для поддержки этого ритма требуется достаточно много
DT
+1, тем более почти всегда стараются стандартизироваться вокруг одного стека и добавление сервисов на другом языке - это большая боль
IK
так вы каждый день релизите то что сделали когда?
DT
trunk-based development
DT
смерджил PR - завтра утром он уехал на Canary, послезавтра в Production
СА
Я точно знаю на нашем примере, что можно перейти от спагетти к проблемно-ориентированной структуре кодовой базы, но это, конечно, не безболезненно и не бесплатно.
СА
Собственно, вот как мы это делали: https://www.alltalks.dev/talk/refaktoring-php-koda-s-primeneniem-ddd
DT
А вот тут вся магия и лежит. Надо очень хорошо следить за схемами API чтобы такое не случалось и обычно никто это не делает.
IK
вшмышле)
тестирование контрактов, contract-first, backward-compatibility
тестирование контрактов, contract-first, backward-compatibility
IK
уж тут точно без магии
IK
и делать v1/v2 апи ВНУТРИ сервисов, а не отдельными сервисами
IK
форкнутыми
DT
почему монолит? если у тебя условно в одной репе есть proj_1, proj_2 … proj_3, library / commons, и собираются эти proj_i в отдельные артефакты - это не монолит, это микросервисы в монорепе
вот если у тебя есть один proj и в зависимости от того, какой конфиг ему на старте подсунуть он выполняет разные роли - тогда это вполне себе монолит
вот если у тебя есть один proj и в зависимости от того, какой конфиг ему на старте подсунуть он выполняет разные роли - тогда это вполне себе монолит
IK
в первом случае собирать то ты отдельно можешь, а релизить нет ну или с трудом
DT
contract-first редко достаточно делают из того что я видел
DT
tell me more about that
СА
Зависит от соотношения объёмов proj_N и library/commons. У нас это называется domain и имеет размер на пару порядков больше, чем все proj_N вместе взятые.
DT
я мейнтейнил монорепу Яндекса, где было 100500 проектов с независимым релизным циклом