Page History
...
Afsnittet her beskriver de skridt der foretages helt fra idé til idriftsættelse for NSP leverancer fremover.
Værktøjerne der indgår i NSP toolchain'en er følgende: Jenkins, VMware Harbor, Docker, Docker Compose, Maven og svn. Slack anvendes til div. notifikationer fra CI-miljøet, SDS, QA og driften, så her kan man også forvente både spørgsmål, svar og notifikationer fra miljøet. Issuetracking foregår i Jira.
Kildekoden oprettes/ændres i svn.nspop.dk/svn/components/<komponent-navn> (herunder ligger trunk, tags og branches).
Når leverandøren 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 og idriftsætter NSP. 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 NSP. 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 registryetregistry'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.
I CI-miljøet opsættes yderligere jobs til at afvikle integrationstests imod en kørende komponent. Disse kan afvikles af NSP imod deployede komponenter på testsystemerne og anvendes til automatisk at afgøre om en komponent er i en tilstand så den kan flytter videre i testmiljøerne eller sættes i produktion.
I det følgende er et overbliksdiagram over leverance pipelinen.
Gliffy Diagram | ||||
---|---|---|---|---|
|
Leverancer af support/vedligehold
Ændringer til NSP-platformen 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 NSP 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.
Leverancer af projekter
Her kan aftales separate projekter under jira.nspop.dk, således leverandøren selv styrer issuetracking osv. efter aftale med NSP. De første leverancer koordineres med NSP via OAT processen. 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".
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.
Adgang til kode repository'et, oprettelse af brugere i LDAP til brug for CI-miljøet, Jira, svn etc gives af NSP.
De enkelte udviklere skal have installeret docker på udviklermaskinerne, således de images NSP stiller til rådighed kan anvendes i den daglige udvikling og til test.
Initiel Opsætning af tool chain
NSP laver et repository til det enkelte projekt under svn.nspop.dk/svn/components, samt oprtter de initielle foldere herunder.
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
For hver komponent opsættes 4 jobs til byg samt deploy. Her tages udgangspunkt i NCC eksempel-koden
...
Dette job starter et release-build job og pusher efterfølgende til registryet, med :<x.y.z> tag
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.
Adgang til kode repository'et, oprettelse af brugere i LDAP til brug for CI-miljøet, Jira, svn etc gives af NSP.
De enkelte udviklere skal have installeret docker på udviklermaskinerne, således de images NSP stiller til rådighed kan anvendes i den daglige udvikling og til test.
Initiel Opsætning af tool chain
NSP laver et repository til det enkelte projekt under svn.nspop.dk/svn/components, samt oprtter de initielle foldere herunder.
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
For hver komponent opsættes 4 jobs til byg samt deploy. Her tages udgangspunkt i NCC eksempel-koden
Jobnavn | adgang | jenkins konfiguration | funktion |
---|---|---|---|
NCC_build | leverandør | Leverandørens jenkinsfil | Jobbet her bygger fra trunk af komponenten. Det bygger på commitændringer, samt kan startes af leverandøren |
NCC_release | NSP | Leverandørens jenkinsfil | Bygger en tagget udgave af kodebasen, ud fra leverandørens jenkinsfil. |
NCC_push_snapshot | leverandør (indirekte) | NSP konfigureret job | Job triggered af trunk-build jobbet. Dette job pusher en :snapshot udgave af dockerimaget der bygges til registryet |
NCC_push_release | NSP | NSP jenkinsfil | Dette job starter et release-build job og pusher efterfølgende til registryet, med :<x.y.z> tag |
Jenkins pipeline fil - leverandøren
Efter opsætning af jenkins, skal leverandøren lave en pipeline fil, beskrivende afviklingen af bygget.
Info |
---|
3.2.1 § I roden af kodebasen skal der findes en groovy-fil kaldet "Jenkinsfile". |
Jenkins pipeline fil - leverandøren
Efter opsætning af jenkins, skal leverandøren lave en pipeline fil, beskrivende afviklingen af bygget.
Info |
---|
3.2.1 § 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. NSP 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.
...
Info |
---|
3.5.2 § Der skal notificeres om fejlede byg |
...
Opsætning af kode repository
Struktur
For hver komponent skal der 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).
...
sub-folder | indhold | krav | note |
---|---|---|---|
configuration | konfigurationsfiler der forventes at være så tilpas dynamiske, at disse skal ændres pr. driftsmiljø | ja | filerne 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. |
database | sql-filer | ja - hvis der anvendes db i enten test eller prod | filerne 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 |
test | 1 stk. docker-compose.yml | ja | docker-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. |
release | 1 stk. docker-compose.yml | ja | docker-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. |
development | 1 stk. docker-compose.yml | nej | dev specifik docker-compose fil, som kan have vol. mapping til target foldere/log foldere osv. |
Environment variable i compose-filerne er tilladte og jo mere konfiguration der kan flyttes derover jo bedre.
Info |
---|
3.3.1 § Der skal i kodebasen være en compose-folder med strukturen beskrevet i det ovenstående. |
...
, log-vol.mapning el. lign. være i denne compose-fil. | |||
development | 1 stk. docker-compose.yml | nej | dev specifik docker-compose fil, som kan have vol. mapping til target foldere/log foldere osv. |
Environment variable i compose-filerne er tilladte og jo mere konfiguration der kan flyttes derover jo bedre.
Info |
---|
3.3.1 § Der skal i kodebasen være en compose-folder med strukturen beskrevet i det ovenstående. |
Dagligt udviklingsarbejde, commit og test
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å 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.
...
Såfremt koden er opdelt i forskellige deployables bør dockerfilerne for de enkelte services også bo under modulerne.
...
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".
Eksempler
NCC
Der er til formålet konstrueret eksempelkode under NCC (NSP Containerized Component) - dette findes her: https://svn.nspop.dk/svn/components/ncc/
...