...

For hver komponent knytter sig et antal jobs i CI-miljøet. Nogle af disse kan afvikles af leverandøren, nogle kan afvikles af QA funktionen og driften. Produktet af disse byggejobs er et/flere docker images, som deponeres på NSP docker registryetregistry'et. Dette findes på registry.nspop.dk. 

...

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. Adgang til kode repositoriet repository'et kan gives af enten driften eller QA funktionen, men skal der oprettes helt nye brugere i LDAP til brug for CI-miljøet, Jira, svn etc. så skal drift/operatør kontaktes.

...

Under pipeline filen skal selve koderepositoryet koderepository'et bygges. Hertil stiller NSP et docker-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.

...

Yderligere er der så mulighed for at opsætte automatisk generering af code-coverage rapporter, testrapporter osv. Det 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).