Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

Gliffy Diagram
namepipeline
pagePin3

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.

...

Jobnavnadgangjenkins konfigurationfunktion
NCC_buildleverandørLeverandørens jenkinsfilJobbet her bygger fra trunk af komponenten. Det bygger på commitændringer, samt kan startes af leverandøren
NCC_releaseNSPLeverandørens jenkinsfilBygger en tagget udgave af kodebasen, ud fra leverandørens jenkinsfil. 
NCC_push_snapshotleverandør (indirekte)NSP konfigureret jobJob triggered af trunk-build jobbet. Dette job pusher en :snapshot udgave af dockerimaget, der bygges, til registryet. Jobbet startes af leverandøren.
NCC_push_releaseNSPNSP jenkinsfil

Dette job starter et release-build job og pusher efterfølgende til registryet, med :<x.y.z> tag

...

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. 

...

sub-folderindholdkravnote
configurationkonfigurationsfiler der forventes at være så tilpas dynamiske, at disse skal ændres pr. driftsmiljøjafilerne 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.

databasesql-filerja - hvis der anvendes db i enten test eller prodfilerne 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
test1 stk. docker-compose.ymljadocker-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.
release1 stk. docker-compose.ymljadocker-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.
development1 stk. docker-compose.ymlnejdev specifik docker-compose fil, som kan have vol. mapping til target foldere/log foldere osv.

...

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

Leverance til QA/PROD

Ved release skal den seneste version af platformen altid anvendes, denne kan findes på registryKoderepositoryet 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.

Info

CI.1.9 § Fejlede byg skal repareres.

Test

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

Info

CI.1.10 § Byg på CI-miljøet skal inkludere unittests


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

Info

CI.1.11 § Releases navngives <kort komponentnavn>-<release nummer x.y.z>

...

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.

...

Code Block
languagegroovy
titleJenkinsfile
#!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()
    }
  }
}

...

Code Block
titleDockerfile
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

...

Code Block
languageyml
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

...

Code Block
languageyml
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

...

Code Block
languageyml
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 }}

...