Integrációs és ellenőrzési technikák (VIMIAC04)
Szoftveres projektek során szisztematikus módszerek alkalmazása és az automatizálás nagyban növeli a készülő szoftver minőségét. Ilyen módszerek közé tartoznak az ezen gyakorlat keretében megismerhető technikák is:
A verziókezelő rendszerek a szoftver forráskód különböző korábbi verzióinak könnyű kezelését teszik lehetővé. Használatuk támogatja a csapaton belüli együttműködést és javítja a fejlesztő csapat hatékonyságát. Mindezeken túl egy olyan központi tárolóként (repository) használható, melyre a fordítás automatizálása és a folytonos integrációs rendszerek épülhetnek.
A szoftver verziókezelő architektúrájának kialakítására két különböző megközelítés terjedt el:
Központosított modell (pl. CVS és Subversion/SVN): ebben a megközelítésben egy szerver létezik, ami tárolja az adatokat és mindenki ide tölti fel és innen tölti le a tárolót. Fontos megjegyezni, hogy ebben az esetben csak a szerveren érhető el a forráskód teljes változtatás története. A letöltés (checkout) során csak egy másolat keletkezik a helyi gépen az aktuális, vagy egy korábbi verzióról.
Elosztott modell (pl. Git): Elosztott megközelítés esetén a felhasználó az adott változat letöltése helyett klónozza (clone) a tárolót a távoli szerverről, melynek eredményeképpen egy teljes, historikus adatokkal rendelkező teljes értékű tároló jön létre (nem csupán egy pillanatkép). A felhasználó ezek után bármilyen műveletet el tud végezni a helyi tárolóján: változtatásokat tud eszközölni, előzményeket tud megtekinteni, korábbi verziókra tud visszaállni, stb. Távoli szerverhez csak abban az esetben kell fordulni és feltölteni (push) a saját módosításait, amennyiben saját munkáját meg szeretné osztani a közösséggel.
Jelenleg a Git a legnépszerűbb verziókezelő rendszer, ezért a tárgy keretében ennek megismerésével foglalkozunk.
Egy fejlesztés aktív folyamata egy Git ág (branch) keretében történik, amely fájlok elkülönített létrehozását, módosítását és törlését jelenti. Ezen elemi módosításokat hozzáadhatjuk/eltávolíthatjuk az aktuális módosításokat tartalmazó indexhez/indexből és végül véglegesíthetjük (commit) azt.
A fejlesztés során több párhuzamos ágat használhatunk, amelyek összeolvasztásával (merge) és elágáztatásával (branch) halad előre a fejlesztés. A Git komplex elágaztatási modellt kínál, amelyben ágak létrehozhatók (create), módosítások tehetők egy-egy ágon, majd végül a különböző módosításokat tartalmazó ágak összeolvaszthatók.
A véglegesített (committed) módosítások a helyi és távoli tárolók között szinkronizálhatók, a távoli tárolóból a helyibe a pull (letöltés (fetching) és összeolvasztás (merging)) művelet segítségével, míg a helyi tárolóból a távoliba a push művelet keretében.
FELADAT További részletesebb információk és parancssori példák megismeréséhez elolvasandó a GitHub Training Manual "Project 1: Caption This" fejezete alatt lévő lépések, amik bemutatják az alapvető fogalmakat és parancsokat.
Több bevált munkafolyamat modell is létezik csapaton belüli együttműködésre, amellyel a szisztematikus fejlesztés megvalósítható a fejlesztői csapatokon belül.
A tantárgy keretében ezen GitHub Flow munkafolyamat modellt használjuk, ami a következő lépésekből épül fel:
Komplex szoftveres projektek fordítása kihívásokkal teli feladat. Különböző modulok és köztes fordítási termékek elkészítése, a függőségek nyilvántartása és integrációs fordítás létrehozása szisztematikus módszert kíván.
Kezdetekben a Make volt az egyetlen fordítást támogató eszköz. Később jelent meg az Ant, ami már több szabadságot biztosított a fordítási folyamat definiálása során, végül az Ivy integrálásával pedig bevezetésre került a függőségek kezelése is.
A Maven volt a következő fordítás automatizálási megoldás, amelyet elsősorban Java projektekben használtak fel. A fordítás két aspektusát célozta meg: egyrészt leírja, hogyan épül fel a fordítási folyamat, másrészt definiálja a függőségeket. Az Ant eszközhöz képest a Maven konvenciókat ajánl a fordítási folyamathoz, ezáltal csak a kivételes eseteket kell kezelni. A Maven vezette be elsőként a függőségek internetről való letöltésének lehetőségét, ami már önmagában megreformálta a szoftver fordításról alkotott képet.
A Gradle már kifejezettem nagy, több-projektes fordítások kezelését biztosítja. Az Ant és a Maven alapjaira épül, kombinálja mindkét eszköz előnyeit és a fordítási konfiguráció leírására bevezetett egy Groovy-alapú szakterület-specifikus nyelvet a korábban használt XML-alapú leírókkal szemben. Ennek eredményeként a Gradle szkriptek áttekinthetőbbek, mint az Ant vagy Maven leírásai. Ezeken túl a Gradle inkrementális fordítási megoldást is kínál, melynek keretében intelligensen érzékeli, hogy mely fordítási lépéseket nem kell újból végrehajtani, mert nem történt változás.
Ezen gyakorlat keretében a Maven megoldást használjuk Java projektek fordítására.
A folytonos integráció alatt legtöbbször az integrációs, fordítási és tesztélési lépések gyakori, akár naponta többszöri végrehajtását értjük. Ez egy folyamat, ami a verziókezelő rendszeren alapul és a fordítás, tesztelés és telepítés lépéseken vezet végig.
Egy folytonos integrációt biztosító keretrendszer a folyamat különböző eszközeinek menedzselt végrehajtását biztosítja és a létrehozott köztes fordítási termékeket kezeli.
.travis.yml) épül, ami a
kóddal együtt a Git tároló gyökérkönyvtárában helyezkedik el és a
folytonos integrációs folyamatot írja le.Ezen gyakorlat keretében a GitHub Actionst használjuk, hogy a folytonos integrációs keretrendszerek alapjait megismerjük.
A GitHub Actions konfigurációs állományai
.github/workflows könyvtárba kerülnek, itt lehet egy-egy
munkafolyamatot (workflow) definiálni. Egy munkafolyamat esetén meg kell
adni, hogy milyen eseményre fusson le. Egy munkafolyamat feladatokból
(job) áll, a feladathoz tartozó lépések (step) egy futtatókörnyezetben
(runner) hajtódnak végre. A futtatókörnyezet lehet egy konténer vagy
virtuális gép. A lépés parancsokat hajthat végre vagy a GitHub vagy
külső források által definiált akciókat hívhat meg.
Az alábbi YAML nyelven írt példa konfigurációs fájl bemutatja a legfontosabb fogalmakat:
# This is a basic workflow to help you get started with Actions
name: CI
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
# Runs a single command using the runners shell
- name: Run a one-line script
run: echo Hello, world!Az órára való felkészüléshez ezen további segédletek elolvasása szükséges: