Планирование зависимостей сборки для конвейера
В этом уроке вы узнаете о коде упаковки, чтобы упростить общий доступ. Вы узнаете, почему следует создавать пакеты, типы пакетов, которые можно создать, где можно разместить пакеты и как получить к ним доступ при их размещении. Вы также узнаете об управлении версиями пакета.
Базы кода всегда растут все больше и сложнее. Это необычно для команды, чтобы написать весь код, который использует их приложение. Вместо этого команда включает существующий код, написанный другими разработчиками. В приложении может быть много этих пакетов или зависимостей. Важно активно управлять этими зависимостями, чтобы иметь возможность правильно поддерживать их и убедиться, что они соответствуют требованиям безопасности.
Давайте вернемся и посмотрим, как дела у команды. Энди собрал команду, чтобы поговорить о потенциальных изменениях в коде, которые помогли бы другой команде.
Собрание команды
Энди: Привет всем. Я общался с командой, которая работает над внутренней системой для Space Game. Они могут использовать модели, которые мы используем для веб-сайта в серверном приложении, которое они планируют писать.
Амита: Что вы означаете по моделям?
Энди: Как вы знаете, веб-сайт Space Game — это приложение ASP.NET Core. Он использует шаблон Model-View-Controller (или MVC) для разделения данных от способа отображения данных в пользовательском интерфейсе. Я думал, что мы могли бы создать пакет, содержащий классы моделей, чтобы любое приложение могло их использовать.
Амита: Что именно цель?
Энди: Обе команды будут совместно использовать одну базу данных. Игра отправляет в базу данных рекорды, мы их читаем и отображаем в таблице лидеров.
Амита: Это имеет смысл. Как мы создадим этот пакет?
Энди: Вот почему я хотела поговорить с вами. У нас есть несколько вариантов, и я хочу выслушать ваши идеи.
Тим: Я хотел бы помочь, но сначала у меня есть некоторые вопросы. Я ничего об этом не знаю и хочу понять, как это работает.
Что такое пакет?
Пакет содержит повторно используемый код, который другие разработчики могут использовать в своих собственных проектах, даже если они его не писали.
Для скомпилированных языков пакет обычно содержит скомпилированный двоичный код, например DLL-файлы в .NET или файлы класса .net в Java. Для языков, которые интерпретируются, а не компилируются, например JavaScript или Python, пакет может содержать исходный код.
В любом случае пакеты обычно сжимаются в ZIP или аналогичный формат. Системы пакетов часто определяют уникальное расширение файла, например nupkg или JAR- для очистки использования пакета. Сжатие позволяет сократить время загрузки и создать один файл для простоты управления.
Пакеты также часто содержат один или несколько файлов, которые предоставляют метаданные или сведения о пакете. Эти метаданные могут описывать, какие задачи выполняет пакет, указывать его условия лицензии, контактные данные автора и версию пакета.
Зачем создавать пакет?
Пакет имеет преимущества по сравнению с дублированием кода.
Одна из причин создания пакета вместо дублирования кода — предотвращение смещения. При дублировании кода каждая копия может быстро разойтиться для удовлетворения требований конкретного приложения. И переносить изменения из одной копии в другую становится непросто. Другими словами, вы больше не можете улучшать код, чтобы приносить другим пользу.
Пакеты объединяют схожие функциональные возможности в один многократно используемый компонент. В зависимости от языка программирования пакет может предоставлять приложениям доступ к определенным типам и функциям, ограничивая доступ к их сведениям о реализации.
Еще одна причина создать пакет заключается в том, что у вас будет согласованный способ создания и тестирования функциональности этого пакета. При дублировании кода каждое приложение может создавать и тестировать этот код разными способами. Один набор тестов может включать проверка, от которых может воспользоваться другой набор.
Недостаток заключается в том, что при использовании пакета у вас появляется еще одна база кода, которую нужно тестировать и обслуживать. При добавлении функций также следует внимательно следить. Как правило, пакет должен содержать функции, которые пользуются множеством видов приложений. Например, Json.NET является популярным пакетом NuGet для .NET, который позволяет работать с JSON-файлами. Json.NET имеет открытый код, поэтому сообщество может предлагать улучшения и сообщать о проблемах.
Если несколько приложений могут воспользоваться тем же кодом, преимущества значительно перевешивают недостатки. У вас есть всего одна база кода, один набор тестов и один процесс сборки для управления.
Как можно определить зависимости?
Если целью является преобразование кода в отдельные компоненты, вам необходимо определить те части вашего приложения, которые можно удалить, упаковать для повторного использования, хранить в центральном месте и снабдить версиями. Возможно, вы даже хотите заменить собственный код сторонними компонентами, которые являются открытый код или лицензией.
Есть множество способов определить возможные зависимости в вашей базе кода. Например, можно проверить код на наличие многократно используемых шаблонов, а также проанализировать архитектуру вашего решения. Ниже приведены некоторые способы определения зависимостей.
Повторяющийся код.
Если некоторые фрагменты кода отображаются в нескольких местах, это хороший признак того, что вы можете повторно использовать код. Централизация этих повторяющихся фрагментов кода и их перепаковка соответствующим образом.
Высокая сплоченность и низкая связь.
Второй подход заключается в поиске элементов кода, имеющих высокую согласованность друг с другом и низкой связью с другими частями кода. В сущности, высокая сплоченность означает сохранение частей базы кода, связанной друг с другом в одном месте. Низкая связь, в то же время, заключается в том, чтобы разделять несвязанные части базы кода как можно больше.
Индивидуальный жизненный цикл.
Найдите части кода с аналогичным жизненным циклом, который можно развертывать и выпускать по отдельности. Если этот код может поддерживаться отдельной командой, это хороший признак того, что вы можете упаковыть его как компонент за пределами решения.
Стабильные части.
Некоторые части базы кода могут быть стабильными и часто изменяться. Проверьте репозиторий кода, чтобы найти код с низкой частотой изменения.
Независимый код и компоненты.
Каждый раз, когда код и компоненты независимы и не связаны с другими частями системы, их можно изолировать в отдельных зависимостях.
Вы можете использовать различные инструменты, помогающие сканировать и изучать вашу базу кода. Эти средства, которые сканируют повторяющийся код и рисуют решения граф зависимостей до инструментов, которые могут вычислять метрики для взаимодействия и согласованности.
Какие виды пакетов существуют?
Каждый язык программирования или платформа предоставляют собственный способ создания пакетов. Популярные системы пакетов предоставляют документацию о том, как работает процесс.
Возможно, вы уже знакомы с этими популярными системами пакетов:
- NuGet: пакеты библиотек .NET
- NPM: пакеты библиотек JavaScript
- Maven: пакеты библиотек Java
- Docker: пакеты программного обеспечения в изолированных единицах, называемых контейнерами
Где размещены пакеты?
Вы можете размещать пакеты в собственной сети или использовать службу размещения. Служба размещения часто называется репозиторий пакетов или реестр пакетов. Многие из этих служб предоставляют бесплатный хостинг для проектов с открытым кодом.
Ниже приведены некоторые популярные службы размещения для типов пакетов, которые мы только что описали:
-
Пакеты NuGet используются для артефактов кода .NET. Эти артефакты включают сборки .NET и связанные файлы, средства и иногда метаданные. NuGet определяет способ создания, хранения и использования пакетов. Пакет NuGet , по сути, является сжатой структурой папок с файлами в формате ZIP и имеет расширение .nupkg .
-
Пакет NPM используется для JavaScript. Пакет NPM — это файл или папка, содержащая файлы JavaScript и файл package.json, описывающий метаданные пакета. Для node.js пакет обычно содержит один или несколько модулей, которые можно загрузить после использования пакета.
-
Maven используется для проектов на основе Java. Каждый пакет содержит файл объектной модели проекта, описывающий метаданные проекта, и является основным модуляем для определения пакета и работы с ним.
-
Пакеты Docker называются образами и содержат полные автономные развертывания. Чаще всего образ Docker представляет программный компонент, который может размещаться и выполняться самостоятельно без каких-либо зависимостей от других образов. Образы Docker слоиются и могут зависеть от других образов.
Веб-канал пакета — это сервер репозитория пакета. Этот сервер может находиться в Интернете или за брандмауэром в сети. Например, можно разместить собственные веб-каналы NuGet с помощью таких продуктов, как Azure Artifacts и MyGet. Вы также можете разместить пакеты в общей папке.
При размещении пакетов за брандмауэром вы можете включить веб-каналы в собственные пакеты. Вы также можете кэшировать пакеты, которым вы доверяете в сети, если системы не могут подключаться к Интернету.
Какие элементы образуют хорошую стратегию управления зависимостями?
Хорошая стратегия управления зависимостями зависит от следующих трех элементов:
Стандартизация.
Стандартизация объявления и разрешения зависимостей позволяет поддерживать повторяемость и предсказуемость вашего автоматического процесса выпуска.
Форматы упаковки и источники.
Каждая зависимость должна быть упакована с помощью применимого формата и хранится в центральном расположении.
Управление версиями.
Необходимо отслеживать изменения, которые происходят со временем в зависимостях так же, как и в собственном коде. Это означает, что зависимости должны быть версиями.
Кто может получить доступ к пакетам?
Многие веб-каналы пакетов предоставляют неограниченный доступ к пакетам. Например, можно скачать Json.NET из nuget.org без необходимости входа или проверки подлинности.
Другие веб-каналы пакетов требуют проверки подлинности. Вы можете выполнить проверку подлинности для доступа к веб-каналу несколькими способами. Например, некоторые виды веб-каналов требуют имя пользователя и пароль. Для других веб-каналов требуется маркер доступа, который обычно представляет собой длинную серию символов, определяющих, кто вы и какие ресурсы у вас есть. Срок действия маркеров доступа истекает после заданного периода времени.
Как указываются версии пакетов?
Схема управления версиями зависит от используемой системы пакетов.
Например, пакеты NuGet используют семантическое версионирование.
Семантическое версионирование — это популярная схема управления версиями. Используется следующий формат:
основной_номер.дополнительный_номер.исправление[-суффикс]
Вот что означает каждый из этих параметров:
- Новый основной номер версии реализует критическое изменение. Приложения обычно требуют обновления того, как они используют пакет для работы с новой основной версией.
- Новая дополнительная версия представляет новые функции, но обратная совместимость с более ранними версиями.
- Новое исправление содержит исправления ошибок с обратной совместимостью, но не новые функции.
- -Суффикс является необязательным и идентифицирует пакет в качестве предварительной версии. Например, 1.0.0-beta1 может определить пакет как первую предварительную сборку бета-версии для выпуска 1.0.0.0.
При ссылке на пакет вы указываете номер версии.
Ниже приведен пример установки пакета с помощью PowerShell и определенного номера версии:
Install-Package Newtonsoft.Json -Version 13.0.1
Что происходит при изменении пакета?
При ссылке на пакет из приложения обычно закрепляете или указываете версию этого пакета, который вы хотите использовать.
Многие платформы позволяют указать допустимые диапазоны версий пакетов для установки. Некоторые также позволяют указать дикие карта, которые мы называем плавающей версией.
Например, в NuGet версия "1.0" означает первую версию, которая равна 1.0, или более позднюю. [1.0] указывает установить только версию 1.0, но не более позднюю.
Ниже приведены несколько других примеров.
| Эта нотация: | Выбирает: |
|---|---|
| (1.0,) | Первая версия больше 1. |
| [1.0,2.0] | Первая версия, которая больше или равна 1.0, и меньше или равно 2.0. |
| (1.0,2.0) | Первая версия больше 1.0 и меньше 2.0 |
| [1.0,2.0) | Первая версия, которая больше или равна 1.0 и меньше 2.0 |
По мере того как каждый из них выпускает новую версию пакета, вы можете оценить изменения и протестировать приложение. Когда вы будете готовы, можно обновить номер версии пакета в конфигурации и отправить изменения в конвейер сборки.
Ниже приведен пример включения пакета Newtonsoft.Json в файл проекта (.csproj) приложения C#. В этом примере указывается версия 13.0.1 этого пакета:
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
</ItemGroup>