First things first! DevOps для проекта Сбербанк Онлайн – это краеугольный камень поддерживающий масштабирование кодовой базы.
Приложение эволюционировало
от классического джентльменского стартерпака в виде монорепозитория с пайплайном построенном на fastlane скриптах
до грандиозной модульной архитектуры с мультирепозиторием и набором инструментов созданных с нуля под наши нужды
В СБОЛе более 100 модулей (читай framework-ов), каждый из которых может быть легко вынесен в отдельный репозиторий или может быть совмещён с любым другим репозиторием. С точки зрения работы над кодом ничего не изменится, для попадания изменений в develop ветку нужен всё ещё 1 PR
До того как мы пришли к целевой картине DevOps архитектуры было много сомнений и периодический мы возвращались к вопросу "Монорепо VS Мультирепо", ведь большинство зарубежных гигантов продвигают Монорепозиторий.
Теоретическое представление о том как это должно работать всегда имело больше плюсов, чем минусов. Поэтому мы единожды законспектировали выводы в Confluence и больше не возвращались к этому вопросу.
Монорепозиторий прост и понятен, но только до тех пор пока вы не начинаете сражение с проблемами. А проблемы не любят говорить о себе сразу, толстая git история в определённый момент заставит вас отказаться от blame-а и сделать форк, либо подружиться с решениями вроде VFSForGit
Проблемы распределённой параллельной разработки имеют свои "проклятья", плоскость этих проблем чем-то схожа с многопоточным программированием. Как мне кажется, тут проще найти компромисс между непрерывностью разработки, сложностью поддержки и стабильностью сборки.
Жизнь в отдельном репозитории стимулирует к созданию отделяемых компонентов, упрощается слитие git историй, снижается нагрузка на BitBucket
Ревью PR-ов:
кросс-ревью всё ещё реализуется за счёт плагинов
упрощение просмотра кода за счёт логической кластеризации модулей
Общее хранилище кода даёт важное преимущество – синхронность вносимых изменений
Один PR лучше, чем несколько последовательно зависящих друг от друга
Эту проблему мы решаем спец. механизмом, который позволяет создавать множество зависящих друг от друга PR-ов и вливать их разом
Инструментарий который стоит за всем этим имеет свою специфику и детали имплементации, могу остановиться и обрисовать более подробно любой аспект нашей инфраструктуры, если от вас будет запрос 😊
