Folyamatos integráció

Question 1

Mi az a folyamatos integráció? (Continuous Integration)

Answer 1

Egy szoftverfejlesztési gyakorlat, amely során a csapat tagjai rendszeresen integrálnak, legalább egy integráció / nap. Minden integráció egy automatikus buildelésből áll, beleértve a tesztek futtatása. Jobb minőségű szoftvert biztosít ez a gyakorlat, mert a hibák rögtön kibuknak.

Question 2

CI fázisai

Answer 2

1. forráskód tárolása
2. verziókezelő
3. build
4. statikus kódanalízis
5. automata unit tesztek futtatása
6. kód lefedettség ellenőrzése
7. alkalmazás elkészítése
8. teszt adatok felállítása, teszt környezetbe helyezés
9. funkcionális tesztek
10. reportok készítése
11. csapatnak elküldeni, akik erre tudnak reagálni.

(Source -> Build -> Test -> Deploy)

Question 3

Source

Answer 3

A CI/CD pipeline alapköve. A forráskód a fejlesztők által folyamatosan frissítve van egy verziókezelő rendszer segítségével. Minden módosítás trackelve van és bármikor visszaállhatnak előző verziókra. A Source stage-ben a commitok, merge requestek triggerelik a következő fázist.

Question 4

Build

Answer 4

Egy kritikus szakasza a pipeline-nak mivel itt lesz a forráskódból futtatható állomány.
Ebben a fázisban kerülnek kezelésre a függőségek, és a statikus kód analízis is lefut. Ha a build elhasal, akkor a fejlesztőknek ezt jelzi a rendszer, illetve a hiba okát is. A build után előáll egy artifact, vagy akár több is ami a következő fázisba átadható.

Question 5

Test

Answer 5

Ebben a fázisban futnak le az automatikus tesztek amelyek garantálják a termék minőségét.
Tesztek amik lefutnak:
* Integrációs tesztek
* Funkcionális tesztek
* Teljesítménybeli tesztek
* Biztonsági tesztek

Question 6

Deploy

Answer 6

A pipeline utolsó fázisa, ahol a program kitelepítésre kerül így elérhetővé válhat a felhasználók számára.

Question 7

CI szabályai

Answer 7

• közös repository használata
• állandó integrálás a fő branchről
• automata gyors build és automata unit tesztek a build részeként
• DEV és UAT környezet a develop branch klónjaként léteznek

Question 8

Folyamatos szállítás (Continuous Delivery)

Answer 8

• A termék mindig készen áll arra, hogy szállítva legyen UAT/QA-ra.
• Folyamatos szállítás és telepítés: UAT-ra.
• Batched deploy PROD-ra.

Question 9

Folyamatos kitelepítés (Continuous Deployment)

Answer 9

Automatikus kitelepítés PROD-ra

Question 10

Continuous Delivery és Continuous Deployment különbség

Answer 10

Continuous Deliverynél a PROD-ra való telepítés manuális addig a Continuous Deployment-nél ez automatikus.

Question 11

CI Stack komponensek és eszközök

Answer 11

• verziókezelő (pl git)
• vcs manager (pl gitlab)
• software project manager (pl Gradle)
• CI servers (pl Jenkins)
• repository management (pl Nexus)
• code review, dokumentáció, hiba keresés. (nem fő része)

Question 12

Jenkins

Answer 12

Ingyenes, pluginokkal tudjuk kiegészíteni, skálázható. Ugyanazok a pluginek megvannak, mint a Gradle-höz is.
Beállításai: header, forrás kód, mire triggerelődjön, gradle wrapper, script beállításai, postbuild akciók beállításai (pl a JUnit teszt eredmények reportolása).
Úgynevezett agentek (slaves) léteznek akik a buildelést, tesztelést végzik így a master servert hagyják más dolgokkal foglalkozni. Skálázhatóságot segítik elő.
Telepítés a Jenkinssel: kontrollálja a folyamatot, nexusból letöltés, cél környezetbe feltöltés, megállítja, újraindítja a folyamatot, ha kell.

Question 13

Repository Management

Answer 13

Szerver alkalmazás (Nexus), bináris komponenseket tároljuk itt (artifactokat).
Azért is használjuk, mert az artifactokat nem akarjuk publikálni.
Nexus karakterisztika a letöltések számát csökkenti, jobb build stabilitás, mert nem függenek külső repotól, snapshot repokkal való kapcsolat magasabb teljesítmény érdekében.
Kontrolálhatjuk az engedélyezett artifactokat. Központi tároló, ahonnan a többi fejlesztő le tudja szedni az artifactokat. Kényelmesebb használat, mert nekünk már nem kell buildelni.

Question 14

Repository management típusai

Answer 14

● hostolt
● proxy (távoli szerverre), hogy a saját gyorsabb legyen
● virtual: adapter különböző repok számára.
Repository csoportok: Sorrendbe tehetők, előírás, hogy ki írhatja elő.
Snapshot: szeretném megosztani valakivel, hogy hogy állok, de még nincs kész. Van redeploy, akárhány verzió lehet.
Release: nincs redeploy, tehát ha kint van az 1.0 nem lehet még egyszer 1.0. Gradle publish-al lehet távoli repoba feltölteni, ha megadjuk ennek címét.