You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Denne side beskriver hvordan man som leverandør til NSP anvender de værktøjer SDS stiller til rådighed. Der er både nogle best practices, samt nogle forventninger til de enkelte leverancer der skal være opfyldt, for at både leverandør, QA, drift og anvendere kan få mest mulig glæde af leverancerne.

Leverance pipeline

Afsnittet her beskriver de skridt der foretages helt fra idé til idriftsættelse for NSP leverancer fremover. 

Ændringer til NSP opstår og håndteres af SDS i Jira på jira.nspop.dk. Man kan således forvente som leverandør at der er nogle givne sager man skal foretage en leverance af - issue-tracking og kommunikation med SDS/QA/Operatør foregår på de enkelte issues i jira. Når en sag er klar til udvikling findes der en versions på det issue ændringen knytter sig til. Kildekoden oprettes/ændres i svn.nspop.dk/svn/components/<komponent-navn> (herunder ligger trunk, tags og branches). 

Når udviklingen mener at have implementeret kodeændringerne laves et release og der oprettes et tag i svn, med den version der findes i på de pågældende sager i Jira. Herefter bygger QA funktionen tagget og leverer dette videre til driften. Bygget foregår på NSP CI-miljøet, der pt. findes på jenkins.nspop.dk. De enkelte leverandører har selv adgang til en række jobs herunder og forventes at kunne se/afvikle disse imod trunk af deres svn repositories.

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 registry'et. Dette findes på registry.nspop.dk. 

Enhver har mulighed for at pull'e images fra NSP docker registryet. 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.

I det følgende er et overbliksdiagram over leverance pipelinen.

<---- tegning af det hele ---- >

De værktøjer der anvendes af toolchain'en er således, Jenkins, VMware Harbor, Docker, Maven og svn. Slack anvendes til div. notifikationer fra CI-miljøet, QA og driften, så her kan man også forvente både spørgsmål, svar og notifikationer fra miljøet.

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. Adgang til kode 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.

Jenkins pipeline fil

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

I det følgende er der beskrevet, hvad jenkinsfilen forventes at indeholde. Byg af kode og byg af docker images er "must haves".

Byg af kode

Under pipeline filen skal selve 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.

Byg af docker image(s)

Efter selve bygget af skal pipelinefilen indeholde et byg af et eller flere dockerimages, som er leverandørens opskrift på hvordan deres komponent skal deployes. NSP stiller et base/platforms image til rådighed, hvor de afhængigheder, 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 tage udgangspunkt i

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

Den nuværende version er 1 - 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.

Optionals...

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

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.

Repository indhold

Indhold i kode repository'et:

main-src-folder
|
+-compose
| |
| +-test
| | |
| | +-docker-compose.yml
| |
| +-release
| | |
| | +-docker-compose.yml
| | 
| +-devel (optional)
| | |
| | +-docker-compose.yml
| |
| +-application.properties
| |
| +-datasource-ds.xml
| |
| +-log4j.xml
| |
| +-other_configuration_files
|
+-Dockerfile (alternativt under modulerne)
|
+-Jenkinsfile
|
+-source_folders_and_files


Jenkinsfile

Indholdet af jenkinsfilen kan der ses et eksempel på her:

Jenkinsfile
#!groovy

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

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

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

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

Dockerfile

Eksempel på dockerfil:

Dockerfile
FROM registry.nspop.dk/platform/nsp:1

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

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



  • No labels