Бесперапынная інтэграцыя — гэта проста. GitHub Actions

Прывітанне, дарагі чытач!

Напэўна ў жыцці кожнага з нас ёсць рэчы, пра якія сорамна ўспамінаць, не тое, што расказваць. І ўсё ж такі я вымушаны прызнацца: да нядаўняга часу coding-interview рэпазітар не выкарыстоўваў магчымасці бесперапыннай інтэграцыі. “Ганьба!” – пракрычаць адні. “Ды каму яна ўвогуле патрэбна ?!” – запярэчаць іншыя.

Са свайго боку я прапаную разам разабрацца, навошта ж распрацоўнікі ўсё часцей выкарыстоўваюць сучасныя інструменты бесперапыннай інтэграцыі, а не распальваюць агонь трэннем двух палачак, і на прыкладзе GitHub Actions дадаць магчымасць бесперапыннай інтэграцыі ў coding-interview рэпазітар.

Дык што ж з сябе ўяўляе бесперапынная інтэграцыя?

Бесперапынная інтэграцыя (continuous integration, CI) – гэта падыход, які мае на ўвазе пад сабой ўнясенне частых змен у агульную кодавую базу, для максімальна хуткага выяўлення памылак, якія ўзнікаюць у тым ліку ў працэсе інтэграцыі.

“А дзе ж тэсты?” – спытае ўважлівы чытач. Ну раз спытае, то чаму б не адказаць? Тэсты з’яўляюцца толькі адной з магчымасцей выяўлення памылак пры частым унясенні змен, што робіць сам працэс бесперапыннай інтэграцыі яшчэ больш надзейным. Таму дэ-факта тэсты з’яўляюцца часткай самога працэсу бесперапыннай інтэграцыі.

На сённяшні дзень існуе вялікая колькасць прылад, якія спрашчаюць працэс бесперапыннай інтэграцыі: Jenkins, Travis, Teamcity, GitLab CI/CD, GitHub Actions і многія іншыя. Бо наш рэпазітар размешчаны на GitHub, таму працягнем знаёмства на прыкладзе яго інструментаў, хоць сама па сабе ідэя ўсюды аднолькавая:

1. Вызначыць падзеі, якія будуць выклікаць тыя ці іншыя заданні пры ўнясенні змен у агульную кодавую базу;
2. Для кожнага задання вызначыць набор дзеянняў (крокаў), якія павінны быць выкананы ў кантэксце гэтага задання.

GitHub Actions настройваюцца з дапамогай канфігурацыйнага файла ў фармаце YAML, які павінен быць размешчаны ў дырэкторыі .github/workflows/. Ніжэй прывядзем прыклад канфігурацыйнага файла:

name: cs-solvers

on: [push]

jobs:
  test:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Setup cs-solvers
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 3.1.101
    - name: Build cs-solvers
      run: dotnet build cs-solvers --configuration Release
    - name: Test cs-solvers
      run: dotnet test cs-solvers

У цэлым самі па сабе канфігурацыі дастаткова інфарматыўныя, але ўсё ж такі дадзім некаторыя тлумачэнні:

• on: [ push ] вызначае спіс падзей, па якіх павінен актывавацца дадзены працэс. Умовы ўзнікнення падзей пры гэтым могуць быць удакладнены, напрыклад назвамі галінак, на якіх дадзеныя падзеі павінны выклікацца ці не выклікацца;
• jobs апісвае спіс заданняў, якія павінны быць выкананы ў кантэксце дадзенага працэсу. У нашым выпадку мы стварылі толькі заданне test;
• runs-on: ubuntu-latest вызначае тып машыны, на якой павінен быць запушчаны дадзены працэс;
• steps вызначае спіс дзеянняў (крокаў), якія неабходна выканаць:
  • actions/checkout@v2 выконвае кланаванне зыходнага кода на сервер выканання;
  • actions/setup-dotnet@v1 настройвае асяроддзе dotnet;
  • dotnet build cs-solvers --configuration Release выконвае зборку праекта;
  • dotnet test cs-solvers запускае тэсты.

Каб паглядзець вынік працы працэсу, неабходна выбраць ўкладку Actions ўнутры рэпазітара:

І выбраць наш працэс:

Засталось дадаць у каранёвы README.md спасылку на вынік працы нашага працэсу ў фармаце:

![BADGE_NAME](https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_NAME>/badge.svg)

Інакш кажучы наступны радок:

![cs-solvers](https://github.com/itdranik/coding-interview/workflows/cs-solvers/badge.svg)

У выніку атрымаем значок статусу ў апісанні праекта.

Зараз выглядае ўсё па-даросламу! Таму можна пачынаць развітвацца. Усім добрага настрою і стабільных зборак!