Page History
...
I det følgende er der beskrevet, hvad jenkinsfilen forventes at indeholde.
Byg af kode
Under pipeline filen skal selve koderepository'et bygges. Hertil stilles NSP Docker Build image til rådighed, med de værktøjer der pt. skal bygges med.
...
Til testformål kan dette image hentes og bruges lokalt. Pipeline filen skal således gøre brug af dette image til byg, idet selve CI-maskinen ikke kan forventes at indeholde hverken den korrekte version af java, maven el. lign.
Byg af docker image(s)
Efter selve bygget af de java deployables projektet indeholder skal pipelinefilen indeholde et byg af et eller flere dockerimages, som er leverandørens opskrift på hvordan deres komponent skal deployes. NSP stiller et platforms image til rådighed, hvor sikkerhedskomponenter og NSP-deployment-tekniske afhængigheder er på plads.
...
Leverandørerne får således et godt indblik i hvordan netop deres komponent kommer til at blive driftet, idet det er nøjagtig samme docker image, der bliver afviklet af QA og driften. Gældende husregler for konfiguration og afhængigheder skal naturligvis stadig overholdes.
Ved release skal den seneste version af platformen altid anvendes, denne kan findes på registry.nspop.dk - de forskellige tags er for nuværende ikke 100% immutable, da mindre opdateringer, der for komponenterne er irrelevante kan medføre nye udgaver af versionen. Ved større ændringer, hvor det forventes at kunne have indflydelse, skifter versionsnummeret.
For referencedokumentation til Dockerfiles kan følgende læses: https://docs.docker.com/engine/reference/builder/
Yderligere
Pipelinefilen har også muligheder for at definere codecoverage samt notifikationer om fejlede byg.
...
| Info |
|---|
3.5.2 § Der skal notificeres om fejlede byg |
Dagligt udviklingsarbejde, commit og test
Leverance til QA/PROD
...
Brug af kode repository
...
Struktur
For hver komponent skal der 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).
For referencedokumentation omkring compose-filer kan følgende læses: https://docs.docker.com/compose/compose-file/
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 |
Til de komponenter der findes på svn.nspop.dk/svn/components er der nogle forventninger til indholdet af. Disse findes for at have en ensretning på kodebasen og yderligere ensretning af leverancerne til driften. Derudover er det også et værktøj til udviklerne selv, da det giver mulighed for hurtigere feedback på deres kodeændringer. På NSP foregår der lige nu en proces omkring at få flyttet alle komponenter fra forskellige svn repo's til svn.nspop.dk/svn/components - når flytningen foretages forventes det samtidig at den enkelte komponent opfylder de beskrevne krav i dokumentet her.
Repository'et oprettes med hhv trunk, branches og tags foldere. Under tags forventes navngivningen at være release-<release nummer x.y.z> - release nummeret bliver brugt til at tagge docker imaget i registry'et med automatisk.
Såfremt koden er opdelt i forskellige deployables bør dockerfilerne for de enkelte services også bo under modulerne.
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).
For referencedokumentation omkring compose-filer kan følgende læses: https://docs.docker.com/compose/compose-file/
Indhold af compose folder
| 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.
| Info |
|---|
3.3.1 § Der skal i kodebasen være en compose-folder med strukturen beskrevet i det ovenstående. |
Dagligt udviklingsarbejde, commit og test
Leverance til QA/PROD
Ved release skal den seneste version af platformen altid anvendes, denne kan findes på registry.nspop.dk - de forskellige tags er for nuværende ikke 100% immutable, da mindre opdateringer, der for komponenterne er irrelevante kan medføre nye udgaver af versionen. Ved større ændringer, hvor det forventes at kunne have indflydelse, skifter versionsnummeret.
Under tags 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 |
|---|
3.6.1 § Releases navngives <kort komponentnavn>-<release nummer x.y.z> |
Såfremt koden er opdelt i forskellige deployables bør dockerfilerne for de enkelte services også bo under modulerne.
Compose folder
Eksempler
NCC
Der er til formålet konstrueret eksempelkode under NCC (NSP Containerized Component) - dette findes her: https://svn.nspop.dk/svn/components/ncc/
...