NuGet

Создание галереи NuGet

**Кларк Селл
**Марк Николс

В этой статье описываются бета-версии NuGet Gallery и NuGetFeed.org.

Продукты и технологии:

NuGet, Visual Studio, Windows PowerShell, ASP.NET MVC, TFS Nugetter

В статье рассматриваются:

• зачем нужен хостинг собственной галереи NuGet;

• простой и быстрый способ размещения галереи NuGet;

• получение исходного кода NuGet Gallery;

• интеграция галереи NuGet с существующими у вас процессами сборки.

Это третья и последняя статья в нашей серии о NuGet — новой экосистеме управления пакетами для разработчиков. NuGet, проект Outercurve Foundation, позволяет .NET-разработчикам использовать, создавать и публиковать пакеты. К этому моменту вы узнали, как управлять библиотеками проектов с помощью NuGet (msdn.microsoft.com/magazine/hh547106) и как стать автором пакетов NuGet (msdn.microsoft.com/magazine/hh708753).
В этой статье мы рассмотрим хостинг вашей галереи NuGet и создание процесса сборки, помогающего управлять вашими пакетами.

Зачем нужен хостинг галереи?

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

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

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

За последнее десятилетие новые методики разработки, в том числе системы автоматизированной сборки и развертывания, способствовали ослаблению остроты этих проблем, но они никогда не были рассчитаны на дистрибуцию и выбор. Для этого предназначены системы управления пакетами.

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

В какой-то мере это очень похоже на то, как действуют сообщества разработчиков открытого исходного кода, использующие проверенные временем и легко масштабируемые методики. Хотя пакеты, которые вы находите на NuGet.org, довольно «крупнозернистые», вы можете следовать тем же методикам при создании своих приложений. Конкретный пример типа ПО, в разработке которого были бы полезны эти методики, — вспомогательная библиотека, создаваемая вашей компанией и поддерживаемая для выпускаемых ею общедоступных продуктов.

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

Просто и быстро

Самый простой способ хостинга собственной галереи NuGet — использование общего файлового ресурса. Это может показаться слегка устаревшим, но, если вам нужно нечто быстрое и простое, это метод работает в высшей степени хорошо. Ресурс можно структурировать в соответствии с вашими потребностями, помещая свои пакеты (т. е. файлы *.nupkg) в любое место этого ресурса. Такой общий ресурс можно называть источником пакетов.

Создав источник пакетов, добавим его в среду разработки. Количество источников пакетов неограниченно, и вы можете легко переключаться между ними. Чтобы отредактировать свои источники пакетов в Visual Studio, выберите Tools | Options | Package Manager | Package Sources (рис. 1). Заметьте, что на момент написания этой статьи текущей была версия 1.5. В разных версиях NuGet возможны небольшие отличия.

Рис. 1. Добавление источника пакетов в Visual Studio

Добавление источника пакетов в Visual Studio

Здесь вы можете добавить, удалить и сменить источник пакетов по умолчанию. При желании то же самое можно сделать в WebMatrix — бесплатной среде веб-разработки. Просто щелкните значок NuGet Gallery в основном меню и выберите Add Source, как показано на рис. 2.

Рис. 2. Добавление источника пакетов в WebMatrix

Добавление источника пакетов в WebMatrix

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

Хотя источник пакетов в файловой системе очень легко подготовить и начать использовать, он совершенно не пригоден для расширения и масштабирования. К счастью, NuGet.org создавался с учетом именно этого; он предоставляет открытую платформу, которую можно брать за основу, расширять и перестраивать под свои потребности. Вы найдете проект NuGet Gallery по ссылке github.com/NuGet/NuGetGallery. NuGet Gallery — это проект ASP.NET MVC 3, созданный на основе Razor, OData, SQL Server и Microsoft Azure.

Лучший способ понять особенности и функциональность NuGet Gallery, полезные для вашей экосистемы разработки, — просто исследовать сайт NuGet.org.

Прежде чем создать и опубликовать какой-либо пакет, вы должны зарегистрироваться. После регистрации вы получаете все права для загрузки своих пакетов, управления ими и редактирования своего профиля. Вы также можете сгенерировать уникальный API-ключ, который позволяет автоматизировать публикацию пакетов в NuGet Gallery (рис. 3). Подробнее о публикации пакетов см. в предыдущей статье из этой серии «Как стать автором NuGet-пакетов».

Рис. 3. Учетная запись пользователя, зарегистрированного в NuGet

Учетная запись пользователя, зарегистрированного в NuGet

Когда вы загружаете пакет в NuGet Gallery, он автоматически занимает свое место в галерее, как показано на рис. 4.

Рис. 4. Пакет, загруженный в NuGet Gallery

A Package Uploaded to the NuGet Gallery

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

Канал передачи пакетов, очевидно, является важнейшей частью всей системы. Это OData-канал, который вы найдете по адресу http://ВашаГалерея/api/v2. Данный URL совпадает с используемым вами в качестве источника пакетов. Без этого канала вся мощь NuGet была бы утрачена.

Приступаем к работе

Прежде чем начать, убедитесь, что к вас установлены следующие продукты и компоненты:

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

Чтобы получить исходный код, вы можете либо скачать архив в формате ZIP (экземпляр мастер-копии базы исходного кода), либо клонировать базу исходного кода с помощью git, например:

$ git clone https://github.com/NuGet/NuGetGallery.git

Сделав это, вы получаете на локальном компьютере всю базу исходного кода. В ее корне вы найдете скрипт Windows PowerShell с именем Build-Solution.ps1. Запустите его для настройки своей системы и компиляции исходного кода.

Если вы запустите исходный код, то заметите, что он работает и выглядит точно так же, как и NuGet.org. Наверное, вам потребуется настройка UI или модификация главной страницы. Это все понятно, но будьте осторожны, особенно если вы хотите сохранить синхронизацию с мастер-копией базы исходного кода.

Интеграция процесса сборки с галереей NuGet

Следующий логичный шаг — интеграция вашей галереи NuGet с существующими процессами сборки. Если у вас нет процесса сборки и вы ищете компактное руководство в стиле «как приступить к работе» с процессами сборки Team Foundation Server (TFS), посмотрите «Microsoft Visual Studio ALM Rangers Build Customization Guide» по ссылке rabcg.codeplex.com.

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

В ходе разработки своего продукта вы многократно проходите процессы кодирования, компиляции, упаковки, передачи (pushing) и публикации. Вы также включаете, как мы надеемся, этап тестирования; результаты тестирования могут заставить вас отказаться от публикации в галерее, если обнаружатся любые проблемы (рис. 5).

Рис. 5. Процесс разработки с применением NuGet

Процесс разработки с применением NuGet

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

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

NuGet.exe — автономное консольное приложение, управляемой параметрами командной строки, но его можно без проблем вызывать из другого процесса, например из TFS Team Build. Team Build выполняет рабочий процесс; в терминологии TFS это набор пользовательских операций, контролируемых шаблоном сборки и инициируемых в соответствии с определением сборки. Одно из готовых решений для автоматизации процесса разработки с применением NuGet — проект NuGetter на nugetter.codeplex.com. Этот проект предоставляет автоматизированную оболочку для приложения NuGet.exe. Мы воспользуемся этим пакетом для демонстрации того, что можно сделать и что нужно продумать при желании автоматизировать создание своих пакетов NuGet.

Как показано на рис. 6, всю необходимую информацию для выполнения упаковки, передачи и публикации вы помещаете в определение сборки в TFS. Создание гибкого и повторяемого процесса сборки для NuGet требует нескольких блоков данных и ключей, которые включают или отключают те или иные части процесса. Эти данные организованы в именованные категории, чтобы у вас было представление о порядке выполнения этапов.

Рис. 6. Шаблон сборки для Nugetter

Шаблон сборки для Nugetter

Раздел PrePackaging используется для более сложной или мульти-инфраструктурной упаковки NuGet, которая требует некоей начальной подготовки. NuGetter может вызывать скрипт Windows PowerShell (при необходимости) для организации файлов библиотеки, чтобы в последующем упростить упаковку. Этот этап не обязателен, поэтому вы можете использовать параметр-флаг Invoke PowerShell Script, чтобы сообщить процессу, нужно ли выполнять этот скрипт.

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

Как видите, все параметры, необходимые для упаковки, включены. Версия, базовый путь (папка source для упаковки), API Key и местоположение галереи (называемой Source) предоставляются как часть определения сборки. Однако безопасность этой информации может оказаться крайне важной для вас. Например, API Key, который позволяет вам — и только вам — передавать пакеты NuGet в галерею. Если этот ключ станет общедоступным, кто угодно сможет от вашего имени передавать фальшивые пакеты. В связи с этим NuGetter позволяет предоставлять либо реальный API Key, либо путь к файлу, где содержится этот ключ. Если вы используете путь к файлу, процесс сборки считывает этот файл, извлекает ключ и применяет его, не указывая ключ в журнале; тем самым обеспечивается защита ключа. Очевидно, что поддержка этой схемы требует сопоставления с идентификатором сервиса сборки прав доступа для чтения этого файла.

Другая потенциальная проблема — управление версией вашего пакета. На рис. 6 номер версии указывается в определении сборки. Но действительно ли вы хотите изменять этот номер в определении сборки? Что будет в случае нескольких процессов сборки — с постоянной интеграцией (continuous integration, CI), ежедневной, по другому расписанию и др.? NuGetter дает вам выбор: вводить версию напрямую или, как в случае с API Key, указывать путь к файлу, который можно будет использовать в нескольких определениях сборок. Все они будут использовать один и тот же номер версии, и вы сможете управлять им из одного места.

Push Destination в этом примере — это NuGet Gallery, но именно здесь вы указываете место размещения собираемого пакета, даже если вы передаете пакет во внутреннюю галерею или в локальное файловое хранилище. Это еще один случай, когда процесс сборки может потребовать вмешательства. NuGet.exe ожидает URL в качестве места назначения, и, если вы передаете пакет в локальное хранилище (для которого нет никакого URL), процессу потребуется правильно интерпретировать формат места размещения. В таком случае передавайте пакеты не через NuGet.exe, а непосредственно из процесса сборки.

Как и NuGet.exe, NuGetter поддерживает автоматизированную публикацию. Просто помните о некоторых подвохах на этом пути, о которых мы рассказывали раньше.

Кстати, вам не придется беспокоиться о том, что ваши потребители могут пропустить какие-нибудь обновления пакета. Сообщество предусмотрело для этого NuGetFeed (github.com/NuGetFeed/NuGetFeed). NuGetFeed позволяет создать собственный RSS-канал для информирования о выбранных вами пакетах. Ваши потребители смогут добавить этот канал в свое средство чтения RSS и узнавать о любых обновлениях.

Другой вариант создания NuGet-канала — MyGet на MyGet.org. MyGet может оказаться отличным средством для тех, кто хочет получить закрытый NuGet-канал для получения информации о вашем списке одобренных пакетов, но не желает тратить время, деньги и усилия на создание и поддержку своей инфраструктуры галереи. MyGet — хостинговое решение, которое позволяет очень быстро создавать галереи, специфичные для ваших требований. Подробнее на эту тему см. сайт MyGet.

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

Заключение

NuGet, несомненно, изменил наш образ мышления в отношении экосистемы управления .NET-пакетами — как общедоступными, так и закрытыми. NuGet Gallery и NuGetFeed — важные компоненты в этой экосистеме. Появление этих инструментов в вашей повседневной деятельности открывает новые возможности. Как отмечалось, NuGet Gallery находится в активной разработке, поэтому обязательно посещайте регулярно github.com/NuGet/NuGetGallery для получения самой свежей информации.

Приведенные в этой статье и другие ссылки вы найдете в on.csell.net/HostingNuGet


Кларк Селл  (Clark Sell) — старший идеолог веб-разработок в Microsoft, работает за пределами Чикаго. Ведет блог csell.net, готовит подкасты на DeveloperSmackdown.com и пишет заметки в twitter.com/csell5.

Марк Николс (Mark Nichols) — старший консультант по программному обеспечению Microsoft за пределами Чикаго. Готовит подкасты на DeveloperSmackdown.com, ведет блог на marnick.net и пишет затеки в twitter.com/mark_nic.

Выражаем благодарность за рецензирование статьи экспертам: Дэвиду Эббо (David Ebbo), Филу Хааку (Phil Haack) и Брэндону Сэтрому (Brandon Satrom).