Масштабирование кодовой базы — это интеграцияЯ, и неизбежно, часть роста компании-разработчика программного обеспечения.
Возможно, вы слышали множество терминов, используемых в качестве ответов — монолиты, монорепозитории, микроинтерфейсы, федерация модулей и многое другое.
В Vercel мы помогли тысячи крупных организаций развивают свою кодовую базу, и у нас есть мнение об оптимальном способе создания программного обеспечения.
В этом посте мы поделимся общими проблемами, возникающими при масштабировании базы кода с течением времени, полезными инструментами с открытым исходным кодом, которые вы можете использовать, а также передовыми практиками и архитектурными шаблонами, которым следует следовать.
В этом посте будут рассмотрены:
Команды изо всех сил пытаются развивать свою кодовую базу, не жертвуя при этом скоростью итерации.
Обычно производительность внешнего интерфейса со временем снижается, поскольку несколько команд работают над одной большой базой кода. Выпуск кода может занять от нескольких часов до нескольких дней.
Командам часто не хватает уверенности в выпуске кода, особенно если новые функции не отстают. флаги функций. Каждая команда может в конечном итоге разрабатывать свою собственную конфигурацию и инструменты для каждого нового проекта вместо того, чтобы повторно использовать и делиться общими фрагментами между командами.
Это может быть сложно даже находить код, когда нужно просмотреть десятки, сотни или даже тысячи репозиториев. Вдобавок ко всему, фронтенд-команды могут столкнуться с трудностями при совместном использовании кода между разными командами и частями пользовательского интерфейса.
Хотя не существует единого решения для устранения всех этих проблем, мы верим в архитектуру, которая увеличивается скорость, а не замедление ее с течением времени.
Многие команды начинают трансформацию с большой монолитной кодовой базы.
Монолиты обладают множеством замечательных качеств, поэтому важно не выбрасывать архитектуру, основанную на последних тенденциях. Вместо этого сосредоточьтесь на болевых точках, которые вы видите, и поймите идеальное состояние разработки программного обеспечения в вашей компании.
Например, успех может выглядеть так:
Частый выпуск новых изменений с быстрыми итерациями
Легкое внедрение новой технологии в существующую кодовую базу.
Предоставление командам возможности независимо работать над различными частями пользовательского интерфейса.
Совместное использование и повторное использование сценариев и конфигураций вместо того, чтобы каждый раз изобретать заново.
Независимо от стадии вашего роста, мы считаем, что вам не нужно жертвовать ни одним из этих пунктов. О некоторых компромиссах мы поговорим позже, но давайте сначала начнем с выбора базовой архитектуры, которая позволяет это сделать: монорепо.
Масштабирование большой кодовой базы начинается с упрощения ее любой чтобы найти код и внести свой вклад. Мы не хотим отказываться от этого качества монолитов.
Но единая монолитная кодовая база, а не более мелкие независимые части, организованные внутри монорепозитория, нарушает два пункта наших критериев успеха.
Вместо того, чтобы иметь более 100 отдельных баз кода, у нового инженера в вашей команде есть одно место, где он может внедриться, настроить локальную среду разработки и начать вносить свой вклад с первого же дня.
Исторически да. Такие компании, как Google и Meta, используют монорепозитории для управления своими невероятно большими базами кода. До недавнего времени инструменты и лучшие практики для реализации этой архитектуры не были легко доступны всем командам.
Теперь инструменты сборки с открытым исходным кодом, такие как Турборепо позволить командам всех размеров использовать монорепозитории.
Turborepo берет уроки и рабочие процессы разработки от гигантов Интернета и доносит их до каждого разработчика. Это упрощает монорепозитории и делает их доступными для всех.
Turborepo — это высокопроизводительная система сборки с разумными настройками по умолчанию и надежными аварийными люками для индивидуальной настройки. Это упрощает разделение вашей кодовой базы на различные разделы, такие как библиотека компонентов, фрагменты внешнего интерфейса для каждой команды и любая другая общая бизнес-логика.
Когда команда вносит изменения в свой раздел пользовательского интерфейса, только измененный код будет создавать или запускать CI-прогоны благодаря мощной системе кэширования Turborepo. Больше не нужно тратить время (и деньги) на ожидание завершения сценариев или сборок для несвязанных изменений.
Кэширование Turborepo делает ваши самые длинные сборки практически мгновенными.
Кэширование Turborepo делает ваши самые длинные сборки практически мгновенными.
Каждая команда может владеть своей частью пользовательского интерфейса с соответствующими проверками кода и владением только этим разделом кодовой базы. Когда им нужно повторно использовать код в разных командах, это просто import заявление прочь.
Монорепозитории — это супервозможность, когда вам нужно вносить обновления в общий код или выполнять более масштабные изменения, затрагивающие различные части пользовательского интерфейса. Вы можете организовать одно изменение для безопасного развертывания кода, не нарушая существующие версии и в идеале с помощью флага функции.
Turborepo также обеспечивает выполнение ваших задач в правильном порядке — распространенная проблема монорепозиториев. Не нужно помнить, собрали ли вы пакет A перед запуском пакета B. Turborepo понимает ваш граф зависимостей и то, как организовать выполнение ваших сценариев.
Монорепозитории позволяют командам независимо выпускать код, будь то отдельный компонент или целая часть приложения. Чтобы поддерживать высокую скорость итерации, вам нужна уверенность в том, что код можно будет развертывать как можно раньше и чаще (и откат!). Мы считаем, что правильным решением для отделения развертываний от выпусков являются флаги функций.
Флаги функций помогают вашей команде безопасно выпускать новый код и экспериментировать с изменениями.
Эта архитектура отделяет развертывание нового кода от выпуска функций. Вы можете изменить пользовательский интерфейс и поведение приложения без необходимости повторного развертывания.
Проверки во время компиляции в вашем монорепозитории обеспечивают безопасность и производительность, не жертвуя при этом возможностью изменять поведение во время выполнения с помощью флагов функций. Лучшее из обоих миров.
Возвращаясь к нашим критериям успеха, отметим, что флаги позволяют часто выпускать новые изменения с быстрыми итерациями.
Имеет смысл задаться вопросом, повлияет ли динамическое чтение флагов, чтобы увидеть, какие функции включены, на производительность сайта. Мы были одержимы этой проблемой и тем, как включить глобальные флаги функций с низкой задержкой. Вот архитектура, которую мы рекомендуем.
Независимо от выбранного вами поставщика флагов, значения флагов должны быть внедрено хранилище данных с малой задержкой в каждом регионе. У Vercel это 18 регионов и более 190 точек присутствия по всему миру.
Чтение с низкой задержкой важно, поскольку значения флагов считываются динамически при каждом запросе. В Vercel значения флагов функций хранятся в Edge Config. Большинство чтений занимают ~5 мсс 99% операций чтения происходит примерно за 15 мс.. Когда у вашего провайдера меняются флаги, изменения автоматически синхронизируются (посредством интеграции) и передаются во все регионы пограничной сети.
Сочетание Vercel Edge Config и интеграции LaunchDarkly для Vercel позволяет нам удобно обновлять конфигурации пометки функций и автоматически отправлять их в наше хранилище Edge Config в режиме реального времени. Мы можем изменить пользовательский интерфейс и поведение нашего приложения без необходимости повторного развертывания, что обеспечивает нам большую гибкость. Низкая задержка, которую обеспечивает Edge Config, снижает накладные расходы на получение конфигураций флагов через HTTP, позволяя нам иметь минимальную задержку и повышать удобство работы для наших пользователей.
Высокопроизводительные команды экспериментируют и быстро вносят изменения. Однако длительное время сборки и развертывания замедляет всех и препятствует экспериментированию.
Единственный способ масштабировать большую кодовую базу — сделать ее как можно более инкрементной, повторно используя уже выполненную работу (посредством кэширования) и запуская только измененный код.
По мере того, как ваше приложение увеличивается в размерах, изменяются и все части процесса сборки:
Проверка типов, тестирование, предварительная отрисовка статических страниц, объединение ресурсов.
Загрузка и установка зависимостей, восстановление кешей сборки
Загрузка результатов сборки, заполнение кешей сборки
С помощью инкрементных сборок с помощью Turborepo мы можем избежать повторных вычислений, разделив каждый «микроинтерфейс» или общую библиотеку в отдельный пакет.
Turborepo планирует параллельное выполнение независимых задач. Результат каждой задачи фиксируется и кэшируется, чтобы избежать повторного вычисления той же работы.
Когда какие-либо входные данные изменяются, Turborepo объявляет задачу недействительной и выполняет ее повторно. Эти изменения значений могут затем распространяться по всему графу зависимостей, обновляя граф с минимальным повторным выполнением.
Turborepo может сохранять уже выполненную работу в удаленном кеше, что позволяет сократить время CI во всех сборках (и при локальной разработке). Удаленный кеш Turborepo на Верселе уже спас клиентов более десяти лет работы в области CI. Пришло время вашей команде вернуться к улучшению качества продукта.
Высокопроизводительные команды уверены в том, что часто выпускают новый код. Однако у частых выпусков есть широко известный и общепризнанный побочный эффект: перекос версий.
Перекос версии происходит, когда разные версии вашего приложения выполняются на клиенте и сервере, что приводит к ошибкам приложения и другому неожиданному поведению.
Например, представьте, что ваше новейшее развертывание изменяет структуру данных, добавляя обязательное поле в профиль пользователя. Старые клиенты не ожидали появления этого нового поля, что приводило к ошибкам при его отправке.
В Vercel у нас была возможность работать с тысячами команд, сталкивающихся с этой проблемой, причем клиенты выполняли развертывание более 6 миллионов раз в месяц.
Защита от перекоса Vercel решает эту проблему на уровне платформы и инфраструктуры, используя блокировка версий, что гарантирует, что клиент и сервер используют одну и ту же версию. В нашем примере устаревшие клиенты продолжают взаимодействовать с серверами, которые понимают старую структуру данных, в то время как обновленные клиенты обслуживаются самым последним развертыванием.
Эпоха масштабных, разовые миграции кончено. Риск и стоимость неудачной миграции слишком высоки. Самый ответственный способ развития большой кодовой базы — это дополнительные миграции. Для этого ваша кодовая база должна состоять из более мелких независимых частей, которые можно будет обновлять или заменять с течением времени.
Компонуемая архитектура позволяет вашей команде выбирать лучшие инструменты для работы и продолжать их развивать по мере необходимости. Сегодня большинство архитектур включают в себя лучшие инструменты для каждого варианта использования в разных облачных вертикалях.
Облако внешнего интерфейса Vercel соединяет и координирует все эти составные части, чтобы обеспечить удобство работы с продуктом. Наша цель — сделать так, чтобы ваша команда инженеров могла как можно быстрее вносить изменения и безопасно выпускать код.
Масштабирование базы кода — это не просто управление ростом, это создание фундамента для повышения базовой скорости итерации. Речь идет о том, чтобы ваша команда могла продолжать приносить пользу вашим клиентам, независимо от того, насколько велика ваша организация.
При наличии правильных инструментов и стратегий это может привести к трансформации вашего бизнеса. Самой большой проблемой являются организационные изменения, необходимые для осуществления этих изменений. Это требует изменения мышления. Речь идет о том, чтобы рассматривать эти проблемы не как препятствия, а как возможности для постоянных итераций и улучшений.
Используйте монорепозитории, используйте флаги функций, внедряйте инкрементальные сборки и применяйте защиту от перекосов для достижения критериев успеха:
Частый выпуск новых изменений с быстрыми итерациями
Алегко внедрить новую технологию в существующую кодовую базу
Предоставление командам возможности независимо работать над различными частями пользовательского интерфейса.
Совместное использование и повторное использование сценариев и конфигураций вместо того, чтобы каждый раз изобретать заново.
Если вы хотите узнать больше об этих практиках, мы хотели бы поговорить с тобой и помогите своей команде принять эти шаблоны.
