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

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

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

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

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

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

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

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

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

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

• 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 спасылку на вынік працы нашага працэсу ў фармаце:

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

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

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