Differences
This shows you the differences between two versions of the page.
|
tsc:laboratoare:laborator-07 [2024/02/29 14:40] 127.0.0.1 external edit |
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 ===== | + | ===== 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 53: | Line 103: | ||
| 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 ==== | + | ==== Exercitii ==== |
| - | 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 clona [[https://github.com/cs-pub-ro/systems-testing | repo-ul]] și a accesa resursele aferente laboratorului: |
| - | 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 === | + | <code bash> |
| - | {{:tsc:laboratoare:lab8_cirunner.png?400|}}\\ | + | student@tsc:~$ git clone git@github.com:cs-pub-ro/systems-testing.git |
| - | Un server de Continuous Integration este o masina accesibila din retea care: | + | student@tsc:~$ cd systems-testing/laboratories |
| - | * 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 | + | student@tsc:~/laboratories$ cd cicd-documentation |
| - | * Monitorizeaza repository-ul de version control pentru a vedea noi commit-uri | + | </code> |
| - | * 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 == | + | Dacă aveți local [[https://github.com/cs-pub-ro/systems-testing | repo-ul]], asigurați-vă că aveți ultima versiune. |
| - | 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]]. | + | <code bash> |
| - | \\ 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]]. | + | student@tsc:~$ cd systems-testing |
| - | \\ 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: | + | student@tsc:~$ git pull |
| - | <code> | + | |
| - | - name: Upload a Build Artifact | + | |
| - | uses: actions/upload-artifact@v3.0.0 | + | |
| - | with: | + | |
| - | # Artifact name | + | |
| - | name: # optional | + | |
| - | # Destination path | + | |
| - | path: # optional | + | |
| </code> | </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 ==== | ||
| - | - Clonati [[https://github.com/Ingineria-Calculatoarelor-ACS-UPB/tree-traversal|repo-ul]]. | ||
| - | - Folositi DoxyGen pentru a genera documentatia deja existenta in acest proiect. Verificati fisierul ''html/index.html'' pentru a observa ce functii sunt deja documentate. | ||
| - | - Adaugati Docstrings si pentru celelalte functii din fisierul ''tree.py''.(TODO 1) | ||
| - Implementati functiile ''_printPreorderTree'' si ''_printPostorderTree'' si scrieti cel putin 2 unit teste pentru functia ''_find''. | - Implementati functiile ''_printPreorderTree'' si ''_printPostorderTree'' si scrieti cel putin 2 unit teste pentru functia ''_find''. | ||
| - In GitHub, creati un action care ruleaza unit testele pentru fiecare commit nou adaugat pe branch-ul ''main''. Pentru a putea face acest lucru, faceti un fork al repository-ului si actualizati branch-ul ''main'' al fork-ului nou creat. | - In GitHub, creati un action care ruleaza unit testele pentru fiecare commit nou adaugat pe branch-ul ''main''. Pentru a putea face acest lucru, faceti un fork al repository-ului si actualizati branch-ul ''main'' al fork-ului nou creat. | ||
| - Actualizati action-ul creat anterior, astfel incat acesta sa se ruleze numai atunci cand se creaza un pull request.([[https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request|Hint]]) | - Actualizati action-ul creat anterior, astfel incat acesta sa se ruleze numai atunci cand se creaza un pull request.([[https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request|Hint]]) | ||
| - Creati o noua actiune care ruleaza doxygen, doar atunci cand se creeaza un nou tag cu o noua versiunea a aplicatiei, si salveaza documentatia ca un artefact.([[https://github.com/marketplace/actions/upload-a-build-artifact|Hint]]) | - Creati o noua actiune care ruleaza doxygen, doar atunci cand se creeaza un nou tag cu o noua versiunea a aplicatiei, si salveaza documentatia ca un artefact.([[https://github.com/marketplace/actions/upload-a-build-artifact|Hint]]) | ||
| + | - Folositi DoxyGen pentru a genera documentatia deja existenta in acest proiect. Verificati fisierul ''html/index.html'' pentru a observa ce functii sunt deja documentate. | ||
| + | - Adaugati Docstrings si pentru restul functiilor din fisierul ''tree.py''. Rulati DoxyGen inca o data pentru a observa modificarile. | ||
| + | <hidden> | ||
| - Actualizati pipeline-ul care ruleaza unit testele, astfel incat acesta sa trimita un mesaj pe Teams in cazul in care nu au trecut toate unit testele. ([[https://medium.com/javarevisited/never-overlook-a-broken-build-again-get-notified-in-microsoft-teams-d020a24292cd|Hint]]) | - Actualizati pipeline-ul care ruleaza unit testele, astfel incat acesta sa trimita un mesaj pe Teams in cazul in care nu au trecut toate unit testele. ([[https://medium.com/javarevisited/never-overlook-a-broken-build-again-get-notified-in-microsoft-teams-d020a24292cd|Hint]]) | ||
| + | </hidden> | ||
| <note tip>Este recomandat sa folositi un fisier .gitignore care va ignora fisierele ce nu sunt necesare a fi incarcate in repo (cum ar fi fisierele executabile compilate). Acest fisier trebuie adaugat in folder-ul repository-ului (preferabil in root-ul acestuia) si adaugat in remote cu urmatorul commit. Un exemplu de continut pentru acest fisier gasiti [[https://pastebin.com/hdiHVEMS|aici]].</note> | <note tip>Este recomandat sa folositi un fisier .gitignore care va ignora fisierele ce nu sunt necesare a fi incarcate in repo (cum ar fi fisierele executabile compilate). Acest fisier trebuie adaugat in folder-ul repository-ului (preferabil in root-ul acestuia) si adaugat in remote cu urmatorul commit. Un exemplu de continut pentru acest fisier gasiti [[https://pastebin.com/hdiHVEMS|aici]].</note> | ||
