Первоначальное открытие

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

Мы рассмотрим весь процесс внедрения от обнаружения до наблюдаемости.
Эта серия сообщений в блоге разбита на 5 частей:

Помещения контекста компании

2022 год — это год многих испытаний для Combo, компании, в которой я в настоящее время являюсь старшим техническим руководителем и руководителем отдела JS.

Одна из целей нашей северной звезды — увеличить общий рост компании. Это означает (среди прочего), что технические команды должны:

  • внедрить новые функции для достижения финансовых целей и целей роста
  • для этого наймите и введите много инженеров-программистов.
  • и последнее, но не менее важное: создавайте и внедряйте сильную культуру разработки.

Утроение размера команды определенно было количественной целью года.

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

Помещения технических репозиториев

В то время ландшафт репозиториев JS-TS состоял из 4+ основных репозиториев GitHub, в которых размещалась большая часть исходного кода внешнего интерфейса компании:

  • мобильные приложения (React-Native)
  • приложения для планшетов (React-Native)
  • бэк-офисное приложение (React-Express)
  • и веб-приложение (React-Express)

Эта «политика множества репозиториев» доставила нам несколько проблем:

  • усилия по настройке должны выполняться параллельно для каждой кодовой базы.
  • инструменты и библиотеки могут быть несовместимы (разные номера версий или даже разные инструменты).
  • рекомендации, определенные на уровне главы, должны быть перенесены в более чем 4 различных репозитория.
  • CLI и манипуляции с кодовой базой различны в каждом репозитории (команды, структура кода…)
  • много кода дублируется (потеря времени на написание, обслуживание и тестирование одного и того же кода)
  • некоторые изменения заставляют создавать PR в нескольких репозиториях (несколько PR, обзоры, гипотетически разные конвейеры CI…)

В этой главе также была поставлена ​​долгосрочная цель: мы хотели начать изучение микроинтерфейсной архитектуры в четвертом квартале (или в начале 2023 года).

Перечисление плюсов и минусов микрофронтенда не является первоначальной целью этой статьи, а проще говоря, мы считаем необходимым, чтобы техническая архитектура соответствовала организационной. Если техническая команда разделена на отряды, имеет смысл разделить приложение таким же образом. (любезно предоставлено Законом Конвея)
Увидимся через несколько месяцев, чтобы получить более полную статью по этой теме!

Итак, вернемся к тому, где мы были.

Выполнение тяжелой работы по архитектурным эволюциям — это миссия моего отряда: отряда платформы. Будучи владельцами этой темы, мы начали изолировать задачу (также известную как «этап открытия»).

После нескольких раундов внутренних (отряд) и внешних (отдел) обсуждений и RFC мы, в конце концов, свели вышеперечисленные пункты к следующей формулировке проблемы:

Как разрешить как обмен общими частями программного обеспечения, так и особенностями команды, и одновременно продвигать инклюзивную технологическую культуру ? (Бонусные баллы, если решение может заставить архитектуру ориентироваться на долгосрочные цели главы)

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