Непрерывная доставка пакета NuGet с использованием TravisCI

January 21, 2020 · 5 мин чтения

Available in: Русский · English · Español · Français · Deutsch · Português · 한국어 · 日本語 · 中文 · العربية · हिन्दी · Polski · Türkçe · Bahasa Indonesia · Nederlands

Недавно я сделал учебник о том, как использовать Travis CI в качестве инструмента для автоматического тестирования вашего кода, который вы только что отправили или пытаетесь отправить в ветку master. Заставить его скомпилировать и протестировать и, наконец, сообщить вам о статусе этого изменения.

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

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

Ну вот этот урок для 😁!

Что нового?

В коде почти нет изменений, нам нужно изменить упаковку, публикацию, а затем то, как мы можем это автоматизировать.

.NET Core CLI

Мы собираемся использовать .NET Core CLI, мы использовали его в предыдущем руководстве с такими командами, как dotnet restore, dotnet build и dotnet test.

Теперь мы собираемся использовать новый набор команд!

[[[ТОК_9]]]

Вы можете посмотреть документацию по этому набору инструментов прямо здесь, но есть краткое объяснение:

dotnet nuget — это набор необходимых инструментов, включающий установку, восстановление, удаление и публикацию пакетов.

NuGet-фид

NuGet — менеджер пакетов для .NET. Клиентские инструменты NuGet предоставляют возможность создавать и использовать пакеты. Галерея NuGet — это центральный репозиторий пакетов, используемый всеми авторами и потребителями пакетов.

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

Получите ключ API

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

Имейте в виду, что срок действия ключа API составляет 365 дней.

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

Создать пакет NuGet

Теперь, когда у нас есть ключ API, наш следующий шаг — сгенерировать пакет NuGet из решения, поэтому откройте решение, в котором у вас есть библиотека классов.

Я буду использовать решение из моего последнего урока, в котором есть класс библиотеки .NET Core под названием CalculatorCLI.Core.

Теперь перейдите в свойства проекта, а затем в Пакет. Вы увидите много информации о пакете, например версию пакета, авторов, описания и многое другое.

Далее следует заполнение, вам не обязательно заполнять все, но важными и обязательными являются Package id, Package version, Authors и Description. Кроме того, если вы попытаетесь загрузить файл самостоятельно, он будет запрашивать License, нам тоже нужно будет добавить его.

Затем вы можете сохранить проект, щелкнув правой кнопкой мыши по проекту и выбрав Pack.

1>------ Build started: Project: CalculatorCLI.Core, Configuration: Debug Any CPU ------
1>CalculatorCLI.Core -> D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\netstandard2.1\CalculatorCLI.Core.dll
1>Successfully created package 'D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\CalculatorCLI.Core.1.0.0.1.nupkg'.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Вывод покажет, что если все в порядке, будет напечатано Successfully created package.

Использование `dotnet`

Как и в предыдущем уроке, мы использовали разные команды для создания и тестирования решения. Теперь мы собираемся добавить больше команд для упаковки и публикации пакетов.

Эти команды:

[[[ТОК_32]]]
[[[ТОК_33]]]

Скрипты развертывания

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

Итак, давайте создадим папку с именем scripts с тремя скриптами bash в корне репозитория.

scripts\compile.sh

#!/bin/sh

echo "Restoring..."
dotnet restore ".\CalculatorCLI\CalculatorCLI.sln"   

echo "Building..."
dotnet build ".\CalculatorCLI\CalculatorCLI.sln" -c Release

scripts\test.sh

#!/bin/sh

echo "Testing..."
dotnet test ".\CalculatorCLI\CalculatorCLI.sln" -c Release -v n

scripts\push.sh

#!/bin/sh

echo "Packing..."
dotnet pack ./CalculatorCLI/CalculatorCLI.Core/CalculatorCLI.Core.csproj -c Release

echo "Pushing..."
dotnet nuget push ./CalculatorCLI/CalculatorCLI.Core/bin/Release/*.nupkg -s "https://nuget.org" -k $NUGET_API_KEY

Улучшение файла `.travis.yml`

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

Теперь мы собираемся сделать с файлом .travis.yml следующее:

Добавьте разные stages
Каждый stage зависит от ветки
Если ваша сборка находится на master, это означает, что пакет необходимо обновить, поэтому мы собираемся отправить наш пакет в каналы NuGet.
Если ваша сборка представляет собой запрос на включение, мы все равно проверим, компилируется ли сборка и протестируем ее, но не будем ее публиковать.

Этапы

Из их документации:

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

Дополнительную информацию о TravisCI stages можно найти на странице документации.

Итак, мы собираемся изменить файл и добавить этапы, что в итоге получится следующим образом:

language:
    csharp
sudo: required
mono: none 
dotnet: 3.0

os:
  - linux
    
jobs:
  include:
    - stage: compile
      script: bash scripts/compile.sh

    - stage: test
      script: bash scripts/test.sh

    - stage: deploy-prod
      if: branch = master AND type = push
      name: "Deploy to NuGet"
      script: bash scripts/push.sh

Как вы можете видеть, у нас есть три разных этапа compile, test и push, последний из которых будет запускаться только тогда, когда branch равен master и это не pull request для него, а только push.

Если вы этого не понимаете, просто загляните в документацию, и все объясняется довольно просто.

Имея это в виду, все pull request не будут ничего отправлять в канал NuGet.

Установка ключа API в качестве переменной среды

Перейдите к настройкам сборки вашего репозитория и добавьте новую переменную среды с именем NUGET_API_KEY со значением, являющимся скопированным ключом API со страницы NuGet.

Создайте `pull request`

Теперь, когда у нас все настроено, пришло время создать pull request и проверить, игнорирует ли компиляция для этого запроса на включение последний stage.

Проверьте сборки

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

Теперь давайте примем pull request и снова проверим сборку, чтобы увидеть, что теперь у нас есть три задания вместо двух.

И как только вы увидите, что сборка поставлена в очередь, вы увидите три задания, включая Deploy-prod в конце.

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

И, очевидно, вы можете увидеть это на странице NuGet.

Вот и все

В этом руководстве мы узнали, как автоматизировать доставку пакетов NuGet. Мы использовали некоторые инструменты, такие как TravisCI, stages и dotnet nuget.

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

Вы можете найти исходный код вместе с файлом .travis.yml прямо здесь, если у вас есть какие-либо вопросы, не стесняйтесь обращаться ко мне в twitter!