Фото: okeykat на Unsplash
У світі DevOps створення CI/CD конвеєрів (pipelines) стало критично важливим елементом сучасної розробки програмного забезпечення. Проте багато розробників часто стикаються з труднощами, пов'язаними із синтаксисом YAML та його обмеженнями. Якщо ви .NET-розробник, чи не було б чудово визначати свої конвеєри за допомогою сильно типізованого зручного API на C# замість YAML?
Саме тут на допомогу приходить ADotNet. ADotNet — це інноваційна .NET бібліотека, яка дозволяє розробникам створювати конвеєри для Azure DevOps та GitHub Actions на C#, забезпечуючи чистіший та більш продуктивний досвід.
У цій статті ми розглянемо бібліотеку ADotNet і порівняємо, як визначаються конвеєри з її потужним API та без нього.
[
ADotNet 4.1.0
ADotNet — це .NET бібліотека, яка допомагає інженерам розробляти конвеєри збірки та релізів на C# без необхідності використання…
www.nuget.org
](https://www.nuget.org/packages/ADotNet?source=post_page-----e7ba87de4bae--------------------------------)
ADotNet спочатку була розроблена Хассаном Хабібом, який уявляв кращий спосіб для .NET-розробників створювати CI/CD конвеєри без складнощів YAML. Усвідомивши її потенціал, бібліотека згодом була розширена та вдосконалена Standard Community, що додала колективні ідеї, розширені функції та надійну підтримку для реальних сценаріїв.
Проблеми з YAML
Уявімо, що потрібно визначити GitHub Actions конвеєр, який будує, тестує та розгортає ваш .NET-додаток. Ось як це зазвичай виглядає на YAML:
Реалізація на YAML
name: Build & Test Pipeline
on:
push:
branches:
- main
pull_request:
branches:
- main
jobs:
build:
name: Build
runs-on: windows-latest
steps:
- name: Check Out
uses: actions/checkout@v2
- name: Setup Dot Net Version
uses: actions/setup-dotnet@v1
with:
dotnet-version: 9.0.101
include-prerelease: true
- name: Restore
run: dotnet restore
- name: Build
run: dotnet build --no-restore
- name: Test
run: dotnet test --no-build --verbosity normal
Хоча YAML ефективний, його складно писати, налагоджувати та підтримувати. Відсутність сильної типізації робить його схильним до синтаксичних помилок, а запам'ятовування точних команд або параметрів може бути виснажливим.
Знайомство з Fluent API ADotNet
ADotNet змінює підхід до створення конвеєрів, дозволяючи розробникам визначати їх на C#, використовуючи переваги сильної типізації, IntelliSense і можливість повторного використання коду. Давайте подивимося, як той самий конвеєр можна визначити за допомогою Fluent API ADotNet (версія 4.1.0 або новіша).
Реалізація на Fluent API
GitHubPipelineBuilder.CreateNewPipeline()
.SetName("Build and Test")
.OnPush("main")
.OnPullRequest("main")
.AddJob("build", job => job
.WithName("Build")
.RunsOn(BuildMachines.UbuntuLatest)
.AddCheckoutStep("Checkout Code")
.AddSetupDotNetStep(
version: "6.0",
stepName: "Setup .NET")
.AddRestoreStep() // default step name is Restore
.AddBuildStep() // default step name is Build
.AddTestStep()) // default step name is Test
.SaveToFile(".github/workflows/pipeline.yml");
Основні переваги Fluent API
- Сильна типізація (Strong Typing): Перевірка на етапі компіляції знижує кількість помилок.
- Зручність читання: Fluent API простіший для читання та написання порівняно з YAML.
- Підтримка IntelliSense: Розробники отримують автодоповнення та документацію безпосередньо в IDE.
4.
Повторне використання: Компоненти конвеєра (pipeline) можна повторно використовувати або динамічно генерувати залежно від потреб проєкту.
Порівняння прикладів
Щоб підкреслити переваги, ось порівняння YAML та ADotNet:
Приклад Fluent API ADotNet
job.AddRestoreStep()
.AddBuildStep()
.AddTestStep();
Коли цей C# код виконується, він генерує наступний YAML:
- name: Restore
run: dotnet restore
- name: Build
run: dotnet build --no-restore
- name: Test
run: dotnet test --no-build --verbosity normal
Чому варто розглянути використання ADotNet
- Продуктивність: Менше часу на налагодження синтаксису YAML, більше часу на розробку функцій.
- Зручність підтримки: Конвеєри, написані на C#, легше рефакторити та версіонувати.
- Гнучкість: Можливість динамічно визначати конвеєри залежно від конфігурації проєкту або введення користувача.
Початок роботи з ADotNet
Щоб почати використовувати ADotNet, встановіть пакет NuGet:
dotnet add package ADotNet
Або
Install-Package ADotNet
Потім визначте свої конвеєри за допомогою Fluent API та збережіть їх як YAML файли:
var pipeline = GitHubPipelineBuilder.CreateNewPipeline()
.SetName("My Custom Pipeline")
.OnPush("main")
.AddJob("build", job => job
.WithName("Build")
.RunsOn(BuildMachines.UbuntuLatest)
.AddRestoreStep()
.AddBuildStep());
pipeline.SaveToFile(".github/workflows/pipeline.yml");
Додавання кастомних кроків до завдань
Однією з найпотужніших функцій ADotNet є можливість визначати кастомні кроки у вашому конвеєрі. Наприклад, ви можете захотіти створити ресурси або виконати кастомну команду під час процесу збірки. Ось як можна додати кастомний крок:
var pipeline = GitHubPipelineBuilder.CreateNewPipeline()
.SetName("Custom Job Pipeline")
.OnPush("main")
.AddJob("custom-job", job => job
.WithName("Custom Job")
.RunsOn(BuildMachines.UbuntuLatest)
.AddGenericStep(
name: "Provision Resources",
runCommand: "dotnet run --project ./Provision/Provision.csproj")
.AddTestStep());
pipeline.SaveToFile(".github/workflows/custom-pipeline.yml");
Коли цей код виконується, він генерує наступний YAML:
name: Custom Job Pipeline
on:
push:
branches:
- main
jobs:
custom-job:
runs-on: ubuntu-latest
steps:
- name: Provision Resources
run: dotnet run --project ./Provision/Provision.csproj
- name: Test
run: dotnet test --no-build --verbosity normal
Висновок
ADotNet долає розрив між простотою YAML та потужністю C#. Завдяки використанню Fluent API, воно дає змогу .NET-розробникам визначати конвеєри у спосіб, який є інтуїтивно зрозумілим, зручним у підтримці та менш схильним до помилок. Якщо ви втомилися боротися з YAML, спробуйте ADotNet і переосмисліть, як ви створюєте CI/CD конвеєри.
Починайте створювати розумніші конвеєри вже сьогодні за допомогою ADotNet!
Перекладено з: Building Seamless CI/CD Pipelines in C# with ADotNet — Fluent Edition