Kuidas korraldada täielik CI/CD tsükkel kolmele…

Täieliku CI/CD tsükli korraldamiseks kolmele meeskonnale saab kasutada järgmisi lähenemisviise ja tööriistu:

Ühine CI/CD platvorm: kasutades tsentraliseeritud platvormi, nagu Jenkins, GitLab CI/CD, GitHub Actions, Azure DevOps või CircleCI. See võimaldab standardiseerida protsesse, tagada läbipaistvus ja hallata kõiki pipleineid ühest kohast.
Monoreposiit või polireposiit:
- Monoreposiit: kõik meeskonnad töötavad ühes repozitsioonis. See nõuab keerukamat harude ja trigereid konfiguratsiooni, et pipleineid käivitada ainult vastavate koodimuudatuste korral. See lihtsustab sõltuvuste haldamist ja versioonikontrolli.
- Polireposiit: iga meeskond omab oma repozitsiooni. See lihtsustab isolatsiooni, kuid keerulisem on hallata sõltuvusi ja protsesside standardiseerimist.
Protsesside standardiseerimine:
- Ühtne pipeline formaat: deklaratiivsete pipeline kasutamine (Jenkinsfile, .gitlab-ci.yml, .github/workflows/*.yml) sammude kirjeldamiseks.
- Ühised teegid/mudelid: korduvate sammude või mallide loomine ühiste ülesannete jaoks (ehitamine, testimine, juurutamine), et vähendada dubleerimist ja tagada järjepidevus.
- Versioonihaldussüsteem (VCS): kasutades ühte VCS-d (Git) selgete harude poliitikatega (Gitflow, Trunk-based Development).
CI/CD konveier:
- CI (Jätkuv integreerimine):
  - Trigerit käivitamine arendusharusse (nt develop või funktsiooniharud).
  - Koodi allika hankimine.
  - Rakenduse ehitamine (kompileerimine, pakendamine).
  - Automaatne testimine (üksus-, integratsioonitestid).
  - Koodi analüüs (statiline analüüs, standardite kontroll).
  - Artefakti loomine (Docker-pilt, JAR, WAR jne) ja selle avaldamine artefaktide hoidlas (Nexus, Artifactory, Docker Registry).
  - Eduka/mitteeduva täitmise teavitamine.
- CD (Jätkuv kohaletoimetamine/paigaldamine):
  - Triger pärast edukat CI lõpetamist ja/või peamise haru ühendamist (nt main/master).
  - Artefakti hankimine hoidlast.
  - Paigaldamine testkeskkonda (dev/staging).
  - Laiaulatuslikum testimine (funktsionaalne, smoke, jõudlus).
  - Jätkuv kohaletoimetamine: peatamine ja manuaalse kinnituse ootamine tootmisse paigaldamiseks.
  - Jätkuv juurutamine: automaatne paigaldamine tootmisse pärast edukat testimist.
  - Konfiguratsiooni haldamise ja juurutustööriistade kasutamine (Ansible, Chef, Puppet) või orkestreerimine (Kubernetes koos Helm/Argo CD/Flux).
  - Rakenduse oleku kontroll pärast juurutamist.
  - Probleemide korral tagasipöördumine (rollback).
Tööriistad:
- VCS: Git (GitHub, GitLab, Bitbucket).
- CI/CD platvormid: Jenkins, GitLab CI/CD, GitHub Actions, Azure DevOps, CircleCI.
- Ehitusvahendid: Maven, Gradle, npm, yarn, pip, Go Modules, Docker build.
- Testiraamid: JUnit, TestNG, Pytest, Mocha, Jest.
- Staatiline analüüs: SonarQube, Linters (ESLint, Pylint).
- Artefakti hoidla: Nexus, Artifactory, Docker Registry.
- Konfiguratsiooni haldus: Ansible, Chef, Puppet.
- Konteineriseerimine: Docker.
- Orkestreerimine: Kubernetes, Docker Swarm.
- Paigaldusstrateegiad: Blue/Green, Canary, Rolling Update.
- Jälgimine ja logimine: Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana).
- Teavitused: Slack, Email, Microsoft Teams.
Vastutuse ja juurdepääsu jaotus:
- Täpne rollide ja juurdepääsu õiguste määratlemine tööriistadele ja keskkondadele iga meeskonna jaoks.
- Salasõnade ja keskkonnamuutujate kasutamine turvaliseks andmete salvestamiseks.
Tagasiside:
- Pipelines integratsioon teavitussüsteemide ja jälgimisvahenditega, et meeskonnad saaksid kiiresti teada probleemidest.

Näide ühe meeskonna struktuurist (GitLab CI/CD näide):

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  TEST_IMAGE: $CI_REGISTRY_IMAGE/testrunner:$CI_COMMIT_SHORT_SHA

build_job:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    # Rakenduse ehitamine (näiteks Java Maveniga)
    # ./mvnw clean package -DskipTests
    # Docker-pildi ehitamine
    docker build -t $DOCKER_IMAGE .
    # Sisselogimine GitLab Container Registry-sse
    docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    # Docker-pildi avaldamine
    docker push $DOCKER_IMAGE
  artifacts:
    paths:
      - target/*.jar # Või muud artefaktid

test_job:
  stage: test
  image: $DOCKER_IMAGE # Kasutame ehitatud pilti või eraldi testpilti
  script:
    # Ühik- ja integratsioonitestide käivitamine
    # Näiteks Java:
    # java -jar target/my-app.jar --run-tests
    # Node.js:
    # npm test
    echo "Testide käivitamine..."
    sleep 10 # Näidis
  needs:
    - build_job

deploy_staging_job:
  stage: deploy
  image: alpine/curl # Või tööriistade pilt juurutamiseks
  script:
    # Juurutamine staging keskkonda
    # Näiteks curl päring või kubectl käsk
    echo "$DOCKER_IMAGE juurutamine stagingusse..."
    # kubectl apply -f k8s/staging.yaml --namespace <team-namespace>
    sleep 10 # Näidis
  environment:
    name: staging
    url: https://staging.your-app.com
  only:
    - main # Trigger on merge into main

deploy_production_job:
  stage: deploy
  image: alpine/curl # Või tööriistade pilt juurutamiseks
  script:
    # Juurutamine tootmisse
    echo "$DOCKER_IMAGE juurutamine tootmisse..."
    # kubectl apply -f k8s/production.yaml --namespace <team-namespace>
    sleep 10 # Näidis
  environment:
    name: production
    url: https://your-app.com
  when: manual # Manuaalne kinnitamine tootmisse
  only:
    - main
  needs:
    - deploy_staging_job

Selline struktuur saab laieneda kolmele meeskonnale, luues eraldi pipleineid (või sektsioone/direktoriaid monoreposiitris), võimalusel kasutades ühiseid malle või teeke korduvate sammude, nagu konteinerite ehitamine või Kubernetes-i juurutamine, lihtsustamiseks. Iga meeskond haldab oma koodi ja pipleineid, kuid see toimub ühel platvormil ja vastavalt standarditele.

Kuidas korraldada täielik CI/CD tsükkel kolmele meeskonnale?