Ko darīsiet, ja vairākas CI komandas ir kopīgas…

Es ieteiktu šādus variantus:

Kopīgo uzdevumu centralizācija. Izolēt kopīgus uzdevumus atsevišķās, atkārtoti izmantojamās komponentēs vai piltuvēs.
- Piemērs: Izveidot centrālo glabātuvi kopīgām būvniecības, testēšanas un izvietošanas skriptēm.

Piltuvju šablonu (Pipeline Templates) izmantošana. Ja CI sistēma atbalsta šablonus (piemēram, GitLab CI, Jenkins Shared Libraries), īstenot kopīgus uzdevumus kā šablonus.

Piemērs: Izveidot šablonu Docker attēla būvēšanai vai Kubernetes izvietošanai.

# .gitlab-ci.yml (fragments)
include:
  - project: 'shared/ci-templates' # Projekts ar šabloniem
    file: '/templates/docker_build.yml' # Šablona fails

build_service:
  extends: .docker_build # Šablona izmantošana
  variables:
    DOCKER_IMAGE_NAME: my-service

Piltuvju (Pipeline) kompozīcija. Sarežģītus piltuvus sadalīt mazākās, atkārtoti izmantojamās daļās, kuras var kombinēt.
Kopīgu rīku ieviešana. Definēt un standartizēt rīkus (piemēram, linters, formātētājus, drošības skenerus), kas tiks izmantoti visās komandās. Koncentrēt to izpildi centrāli.
Regulāra kopīgo piltuvju pārskatīšana un refaktoringa. Veikt periodisku analīzi par kopīgo komponentu izmantošanu un optimizēt tos, ņemot vērā komandu prasību izmaiņas.
Dokumentācija. Izveidot detalizētu dokumentāciju par kopīgo komponentu un šablonu izmantošanu.
Komandu apmācība. Rīkot apmācības komandām par pareizu centrālo resursu un šablonu izmantošanu.
Atsevišķa komanda vai atbildība. Lielās organizācijās var izveidot komandu vai iecelt atbildīgo, kas nodarbosies ar kopīgo CI/CD komponentu uzturēšanu un attīstību.

Izvēle ir atkarīga no izmantotās CI sistēmas, uzņēmuma DevOps prakses attīstības līmeņa un infrastruktūras mēroga. Mērķis — samazināt koda dublēšanu, vienkāršot uzturēšanu un nodrošināt procesu konsekvenci.

Ko darīsiet, ja vairākas CI komandas ir kopīgas uzdevumi?