CI CD

CI/CD

Scop

Scopul implementării unui pipeline de Continuous Integration (CI) și Continuous Deployment/Delivery (CD) este de a asigura:

• Build automat și constant al proiectului (pe fiecare commit sau pull request).
• Testare automată (testele unitare și eventual teste funcționale/integrare).
• Deployment facil (după ce build-ul și testele au trecut cu succes)

Tehnologii folosite pentru CI/CD

• Sistemul de versionare (Git): pentru gestionarea codului sursă.
• Platforma CI/CD: GitHub Actions
• Scripturi de build & test: Direct din Visual Studio 2022.

---

Setup

Pentru a configura proiectul, începem prin clonarea repository-ului folosind comanda:

git clone --recursive https://github.com/unibuc-cs/software-engineering-product-deadzone

Apoi, navigăm în directorul proiectului:

cd software-engineering-product-deadzone

Odată ajunși în director, generăm fișierele proiectului rulând:

generate_project.bat

sau, ne aflăm pe un sistem Unix:

./generate_project.bat

După generarea proiectului, deschidem și compilăm fișierul soluției:

DeadZone.sln

Cerințe adiționale

Visual Studio este instalat cu componenta "Desktop development with C++" activată.

Adăugarea de fișiere noi

Pentru a adăuga fișiere noi în proiect, plasează-le în folderul DeadZone și se rulează din nou scriptul de generare a proiectului:

generate_project.bat

Acest proces va actualiza automat configurația proiectului.

---

Descrierea Environment-urilor

În dezvoltarea acestui proiect, folosirea unor medii separate a ajutat la izolarea diferitelor etape de lucru și la minimizarea riscurilor când apar modificări majore.

1. Development (Dev)

• Scop: Dezvoltare și testare locală/inițială a codului.

• Caracteristici:

  • Codul este în stadiu incipient, cu funcționalități noi sau netestate suficient.
  • Build de tip Debug.
  • Logare extinsă pentru a diagnostica probleme (log-uri detaliate, mesaje de eroare, assert-uri etc.).
  • În Visual Studio 2022, se folosește configurația Debug și se poate rula direct din IDE.
  • Se lucrează pe ramuri de feature separate (branch-uri), iar la final se face un Pull Request către ramura principală (main).
  • Branch-urile curente de testare sunt Player-Spawn-Position, client-server-architecture, gamemodes, menu, multiplayer-menu.
  • Fiecare branch are un nume sugestiv și implementează un anumit feature sau un bug fix legat de modul de funcționare/logica al jocului

• Configurări specifice:

  • Fișiere de tip config
  • config/game.json se ocupă de gestionarea conexiunilor dintre entități și texturi
  • config/input.json se ocupă de maparea tastelor într-un joc. Fiecare acțiune (deplasare, interacțiune, tragere, schimbarea armelor, pauză etc.) este asociată cu un cod de tastă specific.

2. Staging

• Scop: Mediu intermediar pentru testare înainte de lansarea oficială.

• Caracteristici:

  • Cod considerat relativ stabil, dar încă în faza de validare.
  • Build de tip Release.
  • Teste unitare.
  • Generare de hartă:
    • Folosim algoritmul Perlin Noise pe baza dimensiunilor hartei (width, height) pentru a genera harta într-un mod procedural. Astfel la fiecare rulare se generează o mapă nouă conţinând:
      • celule libere
      • pereţi
      • uşi
      • obstacole
      • shop
  • Configurarea logicii modurilor de joc
    • Crearea unui server si stabilirea arhitecturii modurilor de joc, în corespondenţă cu acesta.
      • Zombie Survival
      • Team Deathmatch

Configurari specifice

• config/save.json ...

3. Production

• Scop: Mediu final, pentru utilizatorii/jucătorii reali.

• Caracteristici:

  • Build de tip Release.
  • Stabilitate maximă, testată în prealabil în staging.
  • În pipeline-ul CI/CD, avem un tag care este released pe ramura main.

• Config specific :

  • ?