Как добиться плавного перехода от модели организации «один большой репозиторий VCS для всех продуктов» к модели «множество небольших репозиториев VCS»?

Это распространенный сценарий, когда кодовая база продукта, содержащегося в хранилище в некоторой системе VCS, развивается до такой степени, что эта кодовая база может рассматриваться как содержащая несколько продуктов. Распределение кодовой базы по нескольким репозиториям VCS, каждое из которых предназначено для одного продукта, может использовать несколько преимуществ (см. Ниже преимущества наличия продукта на репозиторий VCS по сравнению с моделью репозитория bloat ). С технической стороны разделение кодовой базы является довольно простым шагом, поскольку большинство VCS поддерживают эту операцию. Однако при таком разделении могут возникнуть технические проблемы, связанные с автоматическим тестированием, непрерывной доставкой, интеграцией услуг или мониторингом (см. Проблемы, возникшие в результате разделения..) Организации, планирующие выполнить такое разделение, поэтому должны знать, как выполнить этот переход как можно более плавно, то есть, не прерывая их доставку и мониторинг конвейера. Первый шаг этого, вероятно, состоит в том, чтобы лучше понять понятие проекта и как определить разделение в монолитной кодовой базе.

В ответах на эти вопросы я бы хотел увидеть:

1. Попытка дать рабочее определение того, что представляет собой продукт, который дает практические критерии для фактического определения продуктов в существующей кодовой базе.

2. Согласно этому рабочему определению, разработайте план, который фактически выполняет раскол. Мы можем сделать упрощенное предположение, что кодовая база обрабатывается полностью автоматизированным sdlc, реализующим непрерывную интеграцию и непрерывную доставку . То есть каждая ветвь проверяется автоматическим тестовым набором, реализованным в текущей кодовой базе, и каждое слияние с какой-то «волшебной» ветвью генерирует артефакты продукта , которые тестируются и развертываются. ( Артефактами продукта являются, например, исходные архивы, документация, двоичные пакеты программного обеспечения, образы Docker , AMI, unikernels.)

3. Такой план удовлетворителен, если он объясняет, как обойти

Проблемы, поднятые расколом

1. Как автоматизированные процедуры тестирования связаны с существующим монолитным хранилищем и разделенными хранилищами?

2. Как процедуры автоматического развертывания связаны с существующим монолитным хранилищем и разделенными хранилищами?

3. Где хранится код для самих процедур автоматического развертывания?

4. Где хранится инфраструктура , стратегии мониторинга и высокой доступности ?

5. Как обеспечить, чтобы разработчик нуждался только в одной кодовой базе за раз (но, возможно, использует артефакты из других кодовых баз).

6. Как может такой инструмент, как git-bisect

Заметка на полях: Преимущества наличия продукта в хранилище VCS по сравнению с моделью хранилища с раздуванием

Наличие нескольких небольших репозиториев, содержащих кодовую базу для конкретного продукта, имеет следующие преимущества по сравнению с подходом «раздутого репозитория»:

1. При использовании разветвленного репозитория трудно откатить релиз, когда продукт нестабилен, потому что история смешана с другой историей продукта.

2. В случае с репозиторием раздувания трудно просматривать историю проекта или операции, а в небольших репозиториях мы с большей вероятностью прочитаем эту информацию. (Это может быть характерно для VCS, таких как git, где, в отличие от svn, мы не можем извлекать поддеревья!)

3. С репозиторием раздувания, мы должны делать намного больше танца ветви, когда мы развиваемся. Если у нас есть N репозиториев, мы можем работать параллельно с N ветвями, если у нас есть только 1 репозиторий, мы можем работать только с одной ветвью или иметь множество рабочих копий, с которыми также приходится сталкиваться.

4. С несколькими небольшими репозиториями журналы дают тепловую карту проекта. Их даже можно использовать в качестве прокси для распространения знаний в команде разработчиков: если я не выполняю коммит в репо X в течение 3 месяцев, было бы хорошо назначить меня в команду, работающую над репо X, чтобы я всегда был в курсе событий в этом компоненте.

5. С небольшими репозиториями легче получить четкий обзор компонента. Если все идет в одном большом хранилище, то нет заметного артефакта, разграничивающего каждый компонент, и кодовая база может легко дрейфовать к большому шарику грязи .

6. Небольшие репозитории заставляют нас работать над интерфейсами между компонентами. Но так как мы хотим иметь хорошую капсуляцию, эту работу мы должны делать в любом случае, поэтому я считаю это преимуществом для небольших репозиториев.

7. С несколькими небольшими репозиториями легче иметь нескольких владельцев продуктов.

8. С несколькими небольшими репозиториями проще иметь простые стандарты кода, которые подходят для полного репозитория и которые могут быть автоматически проверены.

Это увлекательный вопрос, для которого реальные ответы могут не существовать; Я ценю, что, хотя вы пытались сохранить вопрос в контексте VCS, он естественным образом масштабировался до проектирования инфраструктуры и планирования внедрения.

Хотя, похоже, многие из нас работают над этим переходом, который может быть захватывающим, но в то же время таким расстраивающим и болезненным; и я хотел бы поделиться своим опытом и взглядами, стараясь не быть педантичным и просто потому, что я, возможно, не такой хороший инженер, а также не быть скучным.

дизайн

Инфраструктура и архитектура должны идти вместе, чтобы написать современное программное обеспечение. Плотно связанные, если хотите. Может показаться странным, что эти слова используются, но мы, конечно, не говорим о самом коде здесь: я имею в виду, что они должны быть частью одного и того же плана. Когда пришли облака, и люди начали писать программное обеспечение для них, сколько людей тогда поняли, что, поместив туда грязные шарики, они просто будут такими же грязными шариками в другом месте (?) Может быть, несколько дальновидных людей могли предвидеть это, и они, вероятно, работают сегодня в devops. Поскольку devops - это просто модное слово с очень разными значениями для разных людей, я видел места, в которых команда devops сидела на каждом архитектурном собрании; другие места, в которых есть только автоматизация. Чтобы достичь такого рода трансформации, мы должны бороться, чтобы сидеть там.

уверенность

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

Я имею в виду, что кодовая база должна быть изменена в соответствии с новой структурой VCS, и будет очень сложно сохранить ее в процессе разработки. (для этой проблемы могут быть упрощающие стратегии, позже я расскажу об общей, которая может немного помочь распараллелить разработку).

Я уверен, что единственный способ - это поведенческое тестирование, и тот же набор поведенческих тестов должен быть запущен для проверки старого с новой кодовой базой. Мы не проверяем, что приложение ведет себя так, как ожидается, но этот переход не меняет поведение. Неудачные тесты могут быть хорошей вещью! Если они продолжат терпеть неудачу!

На самом деле, очень редко, когда грязевые шары хорошо тестируются; обычно код очень тесно связан, и, скорее всего, для большинства унаследованного кода он не разрабатывался с использованием подхода, основанного на тестировании, даже модульных тестов.

Если такой тестовый код отсутствует, он должен быть написан первым.

стратегия

Да, переход должен быть изолированным; но в то же время интегрированы. Я знаю, что здесь может показаться сумасшедшим, но я не нашел бы других слов, чтобы описать, как уверенность может поддерживать бизнес. Очень немногие, если их вообще нет, компании хотели бы прекратить разработку большой монолитной кодовой базы, чтобы освободить место для этого перехода, и мы не делаем это просто в броске монеты. Возможно, сотни разработчиков могли бы постоянно вносить свой вклад в кодовую базу (я бы использовал здесь фальшивое слово из нашего POV). В то время как наша работа должна быть направлена ​​на определенный моментальный снимок, чтобы обеспечить уверенность, мы должны держать себя в унынии (не в смысле git здесь), чтобы не отставать навсегда.

Стратегия реализации здесь может дать различный опыт. Обычная линия разработки заключается в том, чтобы обернуть / адаптировать (выставляя конечные точки с необязательно переставленными схемами) более новые ветви реализации (в данном случае, в других репозиториях), когда им необходимо взаимодействовать с ядром. Переход с такой стратегией, наряду с рефакторингом, может одновременно предложить сценарий POC для перехода VCS, а затем и поэтапный подход. Видите это как лепить шарик из грязи. Да, жизнь предлагает так много забавных вещей.

Технический долг

Сферы управления бизнесом начали понимать техническую задолженность и учитывать ее. Нет, поцарапайте это, не правда. В то время как все более распространенным является сбор данных измерений и качества с точки зрения статического анализа кода, анализа кода, результатов поведенческих тестов и производительности, а также создания хороших отчетов и всего остального ... все еще невероятно сложно заставить бизнес принять непрерывный подход рефакторинга. Стоимость бизнеса его. «Мы следуем за гибким процессом, и это не внесет никаких улучшений в функции, не так ли?» , По сути, тем самым они сводят на нет существование технического долга. Я рассматриваю это как общий недостающий необходимый шаг, чтобы иметь возможность начать любой переход от монолитной архитектуры к микросервису.

реагрегации

После всего этого вы можете по-прежнему предоставлять один репозиторий-подобный вид, в котором вы можете создать более одного продукта. По любой причине, например, curr / next release, multibrand, клиентские сборки. В этом случае могут помочь такие инструменты, как Google Repo. Сам никогда не пользовался, но я знаю, что мне понадобится один день.

Интеграционное тестирование

В случае микросервисов интеграционное тестирование предполагает иной контекст «тестирования собственного API». Могут и будут существовать более высокие уровни тестирования, функциональности или производительности, но много ли они значат без надлежащего интеграционного тестирования? Это было бы как интеграционное тестирование без юнит-тестирования. Конечно, нет. Вот почему, если вам нужно выполнить git bisect, вы запустите его в ветке хранилища микросервисов, забудьте о запуске этого в хранилище мудбола.

PS. это черновик, мой английский плохой, и я исправлю это однажды