...

Kildekoden oprettes/ændres i svn.nspop.dk/svn/components/<komponent-navn> (herunder ligger trunk, tags og branches). 

...

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.

...

Herunder ses et eksempel på et release-push job på CI-miljøet.

Image Added

Opstart af nyt projekt

Ved opstart af et nyt kodeprojekt initierer projektet kontakten til NSP ang. hvem der skal have adgang til NSP udviklingsmiljøet.

...

NSP laver et repository til det enkelte projekt under svn.nspop.dk/svn/components, samt oprtter de initielle foldere herunder.

...

...

Efter opsætning af jenkins, skal leverandøren lave en pipeline fil, beskrivende afviklingen af bygget.

Denne indeholder opskriften på at bygge komponenten i NSP CI-miljøet. Denne fil er leverandørens "indgang" til byggejobbet. NSP sørger for at opsætte jobs, der anvender denne fil til byg og sikrer at de nødvendige afviklingsrettigheder er tilstede til stede for leverandøren. I udgangspunktet bliver disse jobs sat op til at bygge komponenten så snart der detekteres kodeændringer under /trunk. 

...

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.

...

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

...

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.

...

Environment variable i compose-filerne er tilladte og jo mere konfiguration der kan flyttes derover jo bedre.

...

I det daglige arbejde forventes udviklerne at anvende docker til udvikling og aftestning, således at det setup der leveres også er det er lokalt testes på og verificeres op imod. Afvikling imod de containere der driftes sikrer størst mulig træfsikkerhed, når der skal laves rettelser. Yderligere sikrer anvendelsen af docker-compose setuppet også at der ikke glemmes konfiguration el. lign. ved release, som hvis der fx deployes til en lokal wildfly uden NSP sikkerhedskomponenter eller afvikling imod en database med indhold, der ikke er defineret i det setup der leveres til NSP.

Det forvente

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.

Test

Selve bygget i maven skal kunne afvikles med unittests i NSPbuilder-imaget. 

Leverance til 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 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.

...

Det er altid muligt at få release candidates deployet til test1, ved at oprette/release et rc-tag af kodebasen, dvs "<kort-komponent-navn>-1.0.10rc""<kort-komponent-navn>-x.y.zrc".

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.

Eksempler

NCC

Der er til formålet konstrueret eksempelkode under NCC (NSP Containerized Component) - dette findes her: https://svn.nspop.dk/svn/components/ncc/ 

I NCC koden findes eksempler på hvordan koderepository'et bør struktureres, indhold af jenkins-byggefilen, samt en dockerfil. Yderligere bliver denne også releaset og deployet til test1 og indeholder derfor eksempler på funktionelle test-docker-compose-filer.

...

#!groovy

node {
  try {
    stage('Checkout') {
      checkout scm
    }

    stage('Build') { 
      //This will resolve to docker.image('registry.nspop.dk/platform/nspbuilder:jdk8').inside(){ stage('Build') { 
      docker.image("registry.nspop.dk/tools/nspbuilder:${NSPBUILDER_TAG}").inside(){
        sh "mvn -B clean install"
      }
    }

    stage ('Archive') {
      //This will resolve to docker.build('"registry.nspop.dk/components/ncc:build'${DOCKERTAG}", '--pull .')
      docker.build("${REGISTRYTAG}", '--pull--build-arg BASE_TAG=${NSP_BASE_TAG} .')
    }

  } catch (err) {
    //slackSend channel: '<channelname>', color: 'bad', message: "${env.JOB_NAME} ${env.BUILD_NUMBER} - Build failed ... (<${env.BUILD_URL}|Open>)", tokenCredentialId: 'Slack-Token'
    throw err
  } finally {
    stage ('Clean') {
      deleteDir()
    }
  }
}

...

ARG BASE_TAG=latest
FROM registry.nspop.dk/platform/nsp:1${BASE_TAG}

# Copy configuration files to the module directory
RUN mkdir -p /pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/
COPY etc/module.xml /pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/

# Copy the war file to the deployment directory
COPY target/ncc.war /pack/wildfly8wildfly/standalone/deployments/

compose-filer

...

version: "3.6"

networks:
  nsp_net:
    external: true
  ncc_net:
    external: false

services:
  cradb:
    image: registry.nspop.dk/playground/cradb:latest
    networks:
      - ncc_net
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=yes
  nccdb:
    image: mariadb:latest
    networks:
      - ncc_net
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=yes
    volumes:
      - ../database/01_create_db.sql:/docker-entrypoint-initdb.d/01_create_db.sql
  ncc:
    image: registry.nspop.dk/components/ncc:1.0.9
    ports:
      - "8080"
    depends_on:
      - cradb
      - nccdb
    networks:
      - nsp_net
      - ncc_net
    environment:
      - LOG_MAX_FILE_SIZE=10MB
      - LOG_MAX_BACKUP_INDEX=5
    volumes:
      - ../configuration/ncc.properties:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/ncc.properties
      - ../configuration/log4j-ncc.xml:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/log4j-ncc.xml
      - ../configuration/ncc-ds.xml:/pack/wildfly8wildfly/standalone/deployments/ncc-ds.xml

...

version: "3.6"

services:
  ncc:
    image: registry.nspop.dk/components/ncc:1.0.9snapshot
    volumes:
      - ../configuration/ncc.properties:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/ncc.properties
      - ../configuration/log4j-ncc.xml:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/log4j-ncc.xml
      - ../configuration/ncc-ds.xml:/pack/wildfly8wildfly/standalone/deployments/ncc-ds.xml

...

version: '3.6'
services:
  ncc:
    image: registry.nspop.dk/components/ncc:1.0.9
    volumes:
    - ../configuration/ncc.properties:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/ncc.properties
    - ../configuration/log4j-ncc.xml:/pack/wildfly8wildfly/modules/dk/sds/nsp/examples/ncc/main/log4j-ncc.xml
    - ../configuration/ncc-ds.xml:/pack/wildfly8wildfly/standalone/deployments/ncc-ds.xml
    - /pack/log/ncc:/pack/wildfly8wildfly/standalone/log
    container_name: '{{ comp_ncc_container_name }}'
    restart: unless-stopped
    ports:
    - '{{ comp_ncc_port }}:8080'
    environment:
    - LOG_MAX_FILE_SIZE=10MB
    - LOG_MAX_BACKUP_INDEX=5
    - CRA_SERVER={{ comp_ncc_cra_dbserver }}
    - CRA_USER={{ comp_ncc_cra_dbuser }}
    - CRA_PWD={{ comp_ncc_cra_dbpassword }}

...