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.

Produktet af disse byggejobs er et/flere docker images, som deponeres på NSP docker registryet. Dette findes på registry.nspop.dk.

Husregler omkring 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 er disse der giver mulighed for hurtigere feedback på deres kodeændringer.