Differences
This shows you the differences between two versions of the page.
|
tsc:laboratoare:laborator-07 [2026/03/31 23:42] cezar.craciunoiu [Laborator 07 - CI/CD & Documentation] |
tsc:laboratoare:laborator-07 [2026/03/31 23:46] (current) cezar.craciunoiu Invert order of info |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Laborator 07 - CI/CD. Documentation. Deployment ===== | ===== Laborator 07 - CI/CD. Documentation. Deployment ===== | ||
| + | |||
| + | ==== Continuous Integration ==== | ||
| + | In cadrul Continuous integration practicile de version control, compilarea si testarea automata sunt combinate astfel incat schimbarile care ajung in repository-ul de version control sunt automat verificate, testate si regenerate rapoartele aferente. Este de preferat sa se faca aceste lucruri complet sau partial pentru a reduce riscul ca schimbarile noi sa introduca probleme ca erori de compilare sau bug-uri. \\ Pentru ca sunt multi pasi necesari in a executa un plan de Continuous Integration, durata poate sa fie extrem de mare. Datorita acestui fapt, de fiecare data cand se introduc schimbari noi se va prefera rularea unui plan redus(de exemplu care include compilarea si analiza statica, dar nu include testare si analiza dinamica). Planul complet poate sa fie rulat ocazional, cum ar fi peste noapte, cand poate sa dureze mult mai mult. | ||
| + | Pentru a putea beneficia de Continuous Integration, un proiect trebuie sa aiba mai multe caracteristici: | ||
| + | * Sistem de control al versiuni cu branch principal clar identificat sau set de branch-uri de development | ||
| + | * Build automat | ||
| + | * Dezvoltatori care introduc schimbari frecvent (poate de mai multe ori pe zi) | ||
| + | * Commit-uri introduse pe branch-uri urmarite (ex. cu pull-request asociat) sunt verificate cu un plan minimal de Continuous Integration (compiling, static analysis) | ||
| + | * Testarea se face, ideal, pe o clona a mediului de productie | ||
| + | * Diferit de mediul de dezvoltare | ||
| + | * De obicei verificat rar | ||
| + | * Poate sa foloseasca mai multe masini de rulare pentru a putea viza sisteme cu configuratii diferite sau pentru a paraleliza volumul de munca | ||
| + | Avantaje: | ||
| + | * Problemele de integrare sunt identificate si rezolvate repede | ||
| + | * Schimbarile sunt testate cat mai repede posibil | ||
| + | * Se pune accentul pe check-in-uri frecvente, astfel se incurajeaza modularitatea | ||
| + | Dezavantaje: | ||
| + | * Efort initial ridicat pentru a face setup la sistem | ||
| + | * In functie de structura proiectului, e necesar un anumit nivel de rafinament pentru a pune fiecare pas de verificare intr-un build automat | ||
| + | |||
| + | === Sistem de Continuous Integration === | ||
| + | {{:tsc:laboratoare:lab8_cirunner.png?400|}}\\ | ||
| + | Un server de Continuous Integration este o masina accesibila din retea care: | ||
| + | * Are accesul la informatiile legate de proiectele care trebui rulate, locatia si informatiile de acces la repository-ul de version control, ce branch-uri sa urmareasca, cum sa faca build la proiect si ce rapoarte trebuie sa produca | ||
| + | * Monitorizeaza repository-ul de version control pentru a vedea noi commit-uri | ||
| + | * Cand un push la un branch urmarit apare, server-ul de CI notifica un runner | ||
| + | Un CI runner (sau nod) e un proces pe o masina care: | ||
| + | * Are uneltele necesare pentru a face build la proiect | ||
| + | * Este gestionat de serverul de CI | ||
| + | Cand un runner este notificat de serverul de CI, acesta: | ||
| + | * Cloneaza branch-ul pe care se doreste rularea build-ului din repository-ul de version control | ||
| + | * Ruleaza build-ul | ||
| + | * Publica rapoartele rezultate build-ului | ||
| + | * Poate publica si "artefacte": fisiere generate care contin informatii aditionale cum ar fi versiunea uneltelor folosite in cadrul build-ului | ||
| + | |||
| + | == GitHub Actions == | ||
| + | GitHub furnizeaza o solutie integrata de Continuous Integration printr-un serviciu numit "Actions". | ||
| + | \\ Acest serviciu poate fi accesat din pagina proiectului, selectand tab-ul Actions, de [[https://github.com/sjzeil/CoWeM/actions|exemplu]]. | ||
| + | \\ Pentru a creea un Action nou, este necesara creearea unui fisier de workflow la calea ''.github/workflows/'' din repository. Acest lucru se poate face atat local cat si din GitHub. Fisierul de workflow are extensia ''.yml'' pentru ca foloseste sintaxa [[https://en.wikipedia.org/wiki/YAML|YAML]] si contine indicatii legate de cand si ce este executat in cadrul unui action. Un exemplu de fisier de workflow gasiti [[https://github.com/Ingineria-Calculatoarelor-ACS-UPB/tree-traversal/blob/main/.github/workflows/run.yml|aici]]. | ||
| + | \\ Fisierele ce pot rezulta in urma rularii anumitor pasi pot fi publicate ca artefacte si in cadrul GitHub Actions. Pentru a face acest lucru, puteti folosi urmatoarea sintaxa, dupa pasul de generare al fisierului dorit: | ||
| + | <code> | ||
| + | - name: Upload a Build Artifact | ||
| + | uses: actions/upload-artifact@v3.0.0 | ||
| + | with: | ||
| + | # Artifact name | ||
| + | name: # optional | ||
| + | # Destination path | ||
| + | path: # optional | ||
| + | </code> | ||
| + | <note tip>Generarea unui artefact de build este o extensie a sistemului oferit de GitHub. [[https://github.com/marketplace?type=actions|Aici]] gasiti marketplace-ul cu toate extensiile disponibile pentru GitHub Actions.</note> | ||
| ==== Documentatia ==== | ==== Documentatia ==== | ||
| Line 52: | Line 102: | ||
| Daca sunt necesare alte configuratii, atunci va fi necesara schimbarea fisierului Doxyfile. | Daca sunt necesare alte configuratii, atunci va fi necesara schimbarea fisierului Doxyfile. | ||
| - | |||
| - | ==== Continuous Integration ==== | ||
| - | In cadrul Continuous integration practicile de version control, compilarea si testarea automata sunt combinate astfel incat schimbarile care ajung in repository-ul de version control sunt automat verificate, testate si regenerate rapoartele aferente. Este de preferat sa se faca aceste lucruri complet sau partial pentru a reduce riscul ca schimbarile noi sa introduca probleme ca erori de compilare sau bug-uri. \\ Pentru ca sunt multi pasi necesari in a executa un plan de Continuous Integration, durata poate sa fie extrem de mare. Datorita acestui fapt, de fiecare data cand se introduc schimbari noi se va prefera rularea unui plan redus(de exemplu care include compilarea si analiza statica, dar nu include testare si analiza dinamica). Planul complet poate sa fie rulat ocazional, cum ar fi peste noapte, cand poate sa dureze mult mai mult. | ||
| - | Pentru a putea beneficia de Continuous Integration, un proiect trebuie sa aiba mai multe caracteristici: | ||
| - | * Sistem de control al versiuni cu branch principal clar identificat sau set de branch-uri de development | ||
| - | * Build automat | ||
| - | * Dezvoltatori care introduc schimbari frecvent (poate de mai multe ori pe zi) | ||
| - | * Commit-uri introduse pe branch-uri urmarite (ex. cu pull-request asociat) sunt verificate cu un plan minimal de Continuous Integration (compiling, static analysis) | ||
| - | * Testarea se face, ideal, pe o clona a mediului de productie | ||
| - | * Diferit de mediul de dezvoltare | ||
| - | * De obicei verificat rar | ||
| - | * Poate sa foloseasca mai multe masini de rulare pentru a putea viza sisteme cu configuratii diferite sau pentru a paraleliza volumul de munca | ||
| - | Avantaje: | ||
| - | * Problemele de integrare sunt identificate si rezolvate repede | ||
| - | * Schimbarile sunt testate cat mai repede posibil | ||
| - | * Se pune accentul pe check-in-uri frecvente, astfel se incurajeaza modularitatea | ||
| - | Dezavantaje: | ||
| - | * Efort initial ridicat pentru a face setup la sistem | ||
| - | * In functie de structura proiectului, e necesar un anumit nivel de rafinament pentru a pune fiecare pas de verificare intr-un build automat | ||
| - | |||
| - | === Sistem de Continuous Integration === | ||
| - | {{:tsc:laboratoare:lab8_cirunner.png?400|}}\\ | ||
| - | Un server de Continuous Integration este o masina accesibila din retea care: | ||
| - | * Are accesul la informatiile legate de proiectele care trebui rulate, locatia si informatiile de acces la repository-ul de version control, ce branch-uri sa urmareasca, cum sa faca build la proiect si ce rapoarte trebuie sa produca | ||
| - | * Monitorizeaza repository-ul de version control pentru a vedea noi commit-uri | ||
| - | * Cand un push la un branch urmarit apare, server-ul de CI notifica un runner | ||
| - | Un CI runner (sau nod) e un proces pe o masina care: | ||
| - | * Are uneltele necesare pentru a face build la proiect | ||
| - | * Este gestionat de serverul de CI | ||
| - | Cand un runner este notificat de serverul de CI, acesta: | ||
| - | * Cloneaza branch-ul pe care se doreste rularea build-ului din repository-ul de version control | ||
| - | * Ruleaza build-ul | ||
| - | * Publica rapoartele rezultate build-ului | ||
| - | * Poate publica si "artefacte": fisiere generate care contin informatii aditionale cum ar fi versiunea uneltelor folosite in cadrul build-ului | ||
| - | |||
| - | == GitHub Actions == | ||
| - | GitHub furnizeaza o solutie integrata de Continuous Integration printr-un serviciu numit "Actions". | ||
| - | \\ Acest serviciu poate fi accesat din pagina proiectului, selectand tab-ul Actions, de [[https://github.com/sjzeil/CoWeM/actions|exemplu]]. | ||
| - | \\ Pentru a creea un Action nou, este necesara creearea unui fisier de workflow la calea ''.github/workflows/'' din repository. Acest lucru se poate face atat local cat si din GitHub. Fisierul de workflow are extensia ''.yml'' pentru ca foloseste sintaxa [[https://en.wikipedia.org/wiki/YAML|YAML]] si contine indicatii legate de cand si ce este executat in cadrul unui action. Un exemplu de fisier de workflow gasiti [[https://github.com/Ingineria-Calculatoarelor-ACS-UPB/tree-traversal/blob/main/.github/workflows/run.yml|aici]]. | ||
| - | \\ Fisierele ce pot rezulta in urma rularii anumitor pasi pot fi publicate ca artefacte si in cadrul GitHub Actions. Pentru a face acest lucru, puteti folosi urmatoarea sintaxa, dupa pasul de generare al fisierului dorit: | ||
| - | <code> | ||
| - | - name: Upload a Build Artifact | ||
| - | uses: actions/upload-artifact@v3.0.0 | ||
| - | with: | ||
| - | # Artifact name | ||
| - | name: # optional | ||
| - | # Destination path | ||
| - | path: # optional | ||
| - | </code> | ||
| - | <note tip>Generarea unui artefact de build este o extensie a sistemului oferit de GitHub. [[https://github.com/marketplace?type=actions|Aici]] gasiti marketplace-ul cu toate extensiile disponibile pentru GitHub Actions.</note> | ||
| ==== Exercitii ==== | ==== Exercitii ==== | ||
