...

Efter aftale med projektet opsætter NSP også adgang og jobs på jenkins.nspop.dk - yderligere opsættes også en slack kanal til notifikationer fra CI-miljøet til projektet/leverandøren.

Opsætning af Jenkins - NSP

...

I det følgende er der beskrevet, hvad jenkinsfilen forventes at indeholde. 

Dagligt udviklingsarbejde, commit og test

Leverance til QA/PROD

...

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.

Info
3.3.1 § NSP builder images skal anvendes til at bygge javakoden.

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.

registry.nspop.dk/platform/nsp:<version>

Resultatet af docker bygget skal være et docker-image, som indeholder den byggede komponent og det statiske konfiguration, der måtte skulle til (module.xml, deployables etc).

konfiguration der forventes ændringer til baseret på miljø osv. håndteres særskilt (keystores, datasource-filet etc.).

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.

Desuden kan også lade sig gøre at notificere via slack, hvis byggejobbet går skævt og leverandøren skal underettes.

Dagligt udviklingsarbejde, commit og test

Leverance til QA/PROD

Brug af kode repository

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

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.

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. Dette image skal bruges som udgangspunkt for det image leverandøren bygger. Resultatet af dette skal være et docker-image, som indeholder den byggede komponent og det statiske konfiguration, der måtte skulle til - konfiguration der forventes ændringer til baseret på miljø osv. håndteres særskilt. 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.

Dockerimages der skal driftes på platformen skal derfor altid, med mindre andet er aftalt, tage udgangspunkt i

registry.nspop.dk/platform/nsp:<version>

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

Code-coverage rapporter samt testrapporter skal også være inkluderet i pipelinefilen.

Desuden kan også lade sig gøre at notificere via slack, hvis byggejobbet går skævt og leverandøren skal underettes.

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). 

...