Page History
...
For hver komponent knytter sig et antal jobs i CI-miljøet. Nogle af disse kan afvikles af leverandøren, nogle kan afvikles af NSP. Produktet af disse byggejobs er et/flere docker images, som deponeres på NSP docker registry'et. Dette findes på registry.nspop.dk.
Yderligere produceres der ved byg af et release en docker-compose jinja2 template, som driften anvender sammen med deres deployment ansible kode. Dette er pt. ikke offentlig tilgængeligt.
Enhver har mulighed for at pull'e images fra NSP docker registry'et. Leverandøren leverer opskrifter til at starte komponenten i en testkonfiguration med de nødvendige afhængigheder. Dette sker via compose-filer i en fastlagt directory-struktur under komponentens kodebase.
...
Koderepositoryet på svn.nspop.dk/svn/components anvendes som primært repository og udstilles også for offentligheden. CI-miljøet bygger dagligt eller pr. commit fra trunk og det forventes at man umiddelbart reparerer fejlende builds.
| Info |
|---|
CI.1.9 § Fejlede byg skal repareres. |
Test
Selve bygget i maven skal kunne afvikles med unittests i NSPbuilder-imaget.
| Info |
|---|
CI.1.9 10 § Byg på CI-miljøet skal inkludere unittests |
...
Under tags i koderepository'et forventes navngivningen at være <kort komponentnavn>-<release nummer x.y.z> - release nummeret bliver brugt til at tagge docker imaget i registry'et med automatisk.
| Info |
|---|
CI.1.10 11 § Releases navngives <kort komponentnavn>-<release nummer x.y.z> |
...
Det er altid muligt at få release candidates deployet til test1, ved at oprette/release et rc-tag af kodebasen, dvs "<kort-komponent-navn>-1x.0y.10rczrc".
Ved aflevering af en leverance til QA, forventes man at have afviklet en integrationstest imod docker-compose test-setuppet. Dette sikrer en mere friktionsfri deployment til test1.
...