Share via

Ускорение совместной работы и гибкой разработки с помощью компонента

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

  • Как команды могут эффективно совместно использовать повторно используемые компоненты?

  • Разделы справки позволить моим командам функций быстро выполнять итерацию без шага на работу других команд?

  • Разделы справки дать моей команде автономию, чтобы итерировать в темпе, который подходит для них?

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

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

Компоненты и композиция

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

Исходная композиция

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

После того как вы заросли одно решение, как компонентизация становится интересным вопросом. Мы начали с исходной композиции, где каждый компонент ссылается с помощью ссылки на проект в Visual Studio. Исходная композиция возможна до тех пор, пока источник находится в пределах одной границы композиции: одно решение в одном исходном репозитории.

К сожалению, эти ссылки на проекты начинают разбиваться, когда участвуют несколько решений. На этом этапе, когда решение A зависит от решения B, оно должно ссылаться на встроенные двоичные файлы (например, библиотеки DLL), созданные решением B, — это двоичная композиция.

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

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

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

Состав пакета

Пакеты устраняют многие проблемы ссылки на двоичные файлы. Вместо того, чтобы проверка их в источник, вы можете создать его двоичные файлы в виде пакетов NuGet, которые затем может использовать другое решение A. Если решение A и решение B поддерживаются в виде отдельных компонентов, в которых одновременные изменения между A и B редки, состав пакетов является отличным способом управления зависимостью от A от B. Состав пакета позволяет B выполнять итерацию по собственному курсу, в то время как A бесплатно получать обновления от B при разрешении расписания A, и позволяет нескольким командам выполнять итерацию и обновление решения B без влияния на решение A (или другие решения C или D).

Однако композиция пакетов имеет собственный набор проблем. До сих пор мы рассмотрели простой пример. Масштабирование композиции пакетов до размера большой базы кода (например, Windows или Bing) может вызвать ряд проблем:

  • Понимание влияния критических изменений в компоненте с низким уровнем граф зависимостей становится очень сложной задачей.

  • Зависимости алмазов могут стать значительным препятствием для гибкости . В зависимости от алмазов компоненты B и C зависят от общего компонента А, а компонент D зависит от B и C. Когда компонент A вводит новую версию с критическими изменениями, если B обновляет новую версию, но C не делает, D не может принимать обновления B без введения конфликта зависимостей. В этом простом примере беседа с C может быть все, что необходимо для устранения конфликта. Однако в сложном графе алмазы могут быстро стать неразрешимыми.

  • Когда изменения должны применяться к двум компонентам, состоящим из пакетов, цикл итерации разработчика становится значительно медленнее. Если компонент A обновлен, он требует перестроения, перепаковки и повторной публикации. Впоследствии компонент B должен обновиться до недавно опубликованной версии, чтобы проверить изменения, внесенные в компонент A. Использование исходной композиции, которая позволяет одновременно создавать компоненты A и B, будет последовательно предоставлять более быстрый цикл итерации для разработчиков.

Что следует использовать

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

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

  • Можно ли ожидать частые проверка в наборах, установленных для моих команд?

  • Отвечает ли одна команда за весь набор?

  • Для одного набора используется общий срок выпуска?

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