Page History
Denne side beskriver hvordan man som leverandør til NSP anvender de værktøjer SDS stiller til rådighed i CI/CD sammenhæng. Der er både nogle best practices, samt nogle forventninger til de enkelte leverancer der skal være opfyldt, for at både leverandør, QA, drift og anvendere kan få mest mulig glæde af leverancerne.
Continuous Integration / Continuous DeliveryBegreberne handler i NSP sammenhæng om at der for CI-delen ønskes hurtige tilbagemeldinger og en høj grad af inddragelse af leverandøren i selve miljøet, uden at bryde de governance regler der gælder for platformen. Leverandøren har således selv mulighed for at definere samt overvåge byg af egne komponenter. For CD-delen handler det om at have en så gnidningsfri overlevering fra leverandør og hele vejen til drift, hvorfor der i dette projekt er blevet defineret nogle afleveringsforretninger, der kan anvendes på tværs af leverandører og sikrer at der er mindst mulig vej fra leverandør til drift, igen med henblik på de gældende regler. Med dette udgangspunkt er leverandøren således selv med til at definere deployment-tekniske dele af egne komponentet. Yderligere har man som leverandør også mulighed for nemt at hente andre (egne såvel som andre leverandøreres) komponenter og afvikle disse i testsammenhæng.
Leverance pipeline
Afsnittet her beskriver de skridt der foretages helt fra idé til idriftsættelse for NSP leverancer fremover.
...
For hver komponent opsættes 4 jobs til byg samt deploy. Her tages udgangspunkt i NCC eksempel-koden
| Jobnavn | adgang | jenkins konfiguration | funktion |
|---|---|---|---|
| NCC_Build | leverandør | Leverandørens jenkinsfil | Jobbet her bygger fra trunk af komponenten. Det bygger på commitændringer, samt kan startes af leverandøren |
| NCC_Release | NSP | Leverandørens jenkinsfil | Bygger en tagget udgave af kodebasen, ud fra leverandørens jenkinsfil. |
| NCC_snapshot_push | leverandør (indirekte) | NSP konfigureret job | Job triggered af trunk-build jobbet. Dette job pusher en :snapshot udgave af dockerimaget der bygges til registryet |
| NCC_release_push | NSP | NSP jenkinsfil | Dette job starter et release-build job og pusher efterfølgende til registryet, med :<x.y.z> tag |
Compose folder
For hver komponent skal der ligeledes være en compose folder under roden af repository'et. Folderen skal indeholde en docker-compose fil, der udtaler sig om hvordan komponenten startes i testsammenhæng og een der udtaler sig om hvordan komponenten startes, når denne skal deployes i NSP miljøerne. Yderligere kan man som leverandør have stor fordel af at lave en development compose-fil, som kan anvendes i udviklingsammenhæng (med mulighed for at mappe stier til deployment af war-filer og specificere hvor dockerfiler findes til build øjemed).
...
Indhold af compose folder
| sub-folder | indhold | krav | note |
|---|---|---|---|
| configuration | konfigurationsfiler der forventes at være så tilpas dynamiske, at disse skal ændres pr. driftsmiljø | ja | filerne indeholdt i folderen forventes at defaulte til testopsætning. Det er således forventningen at disse er funktionsdygtige ved afvikling af docker-compose.yml filen under test (og evt. development) sub-folderen. Konfigurationsfilerne herunder må ikke samtidig være bygget ind i docker-imaget for komponenten. Disse volume mappes ind via docker-compose. |
| database | sql-filer | ja - hvis der anvendes db i enten test eller prod | filerne prefikses med timestamp. Det er forventningen at disse vol. mappes ind i en db-container til testsammenhæng og i øvrigt er beskrevet i installationsvejledningen ifht. hvilke evt. skal afvikles for at idriftsættelse af komponenten er mulig (oprettelse af db osv.). Der skal også være beskrevet hvilke filer der udelukkende er til test |
| test | 1 stk. docker-compose.yml | ja | docker-compose fil, der kan launche komponenten og dennes afhængigheder. Mock services, database osv skal startes i denne compose fil, yderligere kan man opsætte portmapning osv. Filen skal kunne afvikles med "docker-compose up" og det er forventningen at leverandørens integrationstest kan afvikles imod dette setup. Kodebasen indeholder således en opskrift til at startet komponenten lokalt, blot ved at hente compose-folderen med indhold. Konfigurationsfiler vol. mappes ind. Mock-services bør i udgangspunktet også overholde husreglerne. |
| release | 1 stk. docker-compose.yml | ja | docker-compose fil, der udelukkende indeholder volume mapning af de enkelte konfigurationsfiler fra configuration sub-folderen og så har de korrekte image angiverser for de enkelte services. Denne compose-fil bliver i byggemiljøet beriget og bliver basis for den Jinja2 template der kan idriftsætte komponenten i de forskellige miljøer. Der skal således ingen portmapning, netværk, log-vol.mapning el. lign. være i denne compose-fil. |
| development | 1 stk. docker-compose.yml | nej | dev specifik docker-compose fil, som kan have vol. mapping til target foldere/log foldere osv. |
Environment variable i compose-filerne er tilladte og jo mere konfiguration der kan flyttes derover jo bedre.
...