Denne guide er ikke længere gyldig - En opdatering er på vej


Version 1.0 August 2012

Introduktion

Denne note beskriver anvendelsen af Subversion (SVN) i NSP projektet til henholdsvis modtagelse af komponentleverancer og leverance af NSP komponenter til drift. Noten forholder sig eksplicit ikke til hvorledes komponentleverandører anvender versionskontrol, ej heller hvilken versionskontrol leverandører anvender i forbindelse med komponentudviklingen.

Fokus er på overdragelse af artefakter til NSP kvalitetssikring og drift, hvorfor noten primært omhandler processerne omkring overdragelse, mens strukturen er sekundær. I dette dokuments afsnit "Illustreret leveranceprocess" findes en oversigt, som viser leveranceprocessen.

1 Roller

Der findes en række aktører i landskabet omkring NSP, navnligt:

  • Komponentleverandør: udvikler og vedligeholder en eller flere software-komponent(er) der er hjemmehørende på NSP. Leverer sine produkter til NSP leverandøren.
  • NSP Operatør: har den administrative rolle ifht. udvikling, vedligehold og drift.
  • NSP Leverandør: tester og kvalitetssikrer software-komponenter modtaget af Komponentleverandøren inden overdragelse til NSP driftsleverandør.
  • NSP Driftsleverandør: varetager idriftsættelsesopgaver og drift af NSP systemet. Drifter også SVN i NSP projektet.

2 Komponentleverancer

Ved komponentleverance forstås en aftalt overdragelse af en specifik komponentversion fra Komponentleverandør til NSP Leverandør med henblik på QA af komponenten til NSP platformen. Betragtet over tid vil hver komponent være afleveret i flere versioner, som af hensyn til sporbarhed derfor skal afleveres i NSP projektets SVN repository.

Som udgangspunkt skal NSP Leverandøren informeres når nye leverancer ligger klar i repositoriet. Komponentleverandøren kan frit vælge fremgangsmåde og værktøjer ved overførsel af en leverance til respositoriet.
I uopsættelige tilfælde kan NSP leverandøren være behjælpelig med at indlæse en leverance i repositoriet. Artefakterne skal leveres til repositoriet som beskrevet i det følgende.

2.1 Modtagelse af komponent

En leverance består blandt andet af, men er ikke begrænset til:

  • Kildekode, inkl. test (Husregler 1.0, §2.4.2 og §2.4.3)
  • Stamdata
  • Testdata eller instrumenter til at skabe testdata
  • Dokumentation (Husregler 1.0, §2.4.1)
  • Testresultater

Hver Komponentleverandør har et område i SVN, hvor denne placerer leverancer. Det anbefales at benytte et standard SVN layout (med et trunk-, branches- og tags-directory) (se: http://svnbook.red-bean.com/en/1.7/svn.tour.importing.html#svn.tour.importing.layout), Da det eneste ufravigelige krav er, at hver leverance skal være endelig og kunne refereres entydigt, stilles der intet krav om at Komponentleverandøren laver tags fra trunk. Med andre ord kan trunk være tom. Filerne, som udgør leverancerne forventes at være umiddelbart tilgængelige i SVN, dvs. udenfor enhver form for arkiv (.zip, .gz, .tar, .jar, .war, .ear etc). Som udgangspunkt er området for Komponentleverandøren i SVN defineret som vist på Figur 1.

Det anbefales Komponentleverandøren at anbringe leverancer i 'tags'-directory.

Figur 1: NSP respository, standard SVN layout

Komponentleverandører har frie hænder til at afvige fra anbefalingen omkring SVN layout, hvis det ønskes, men bør i dette tilfælde nøje overveje om det skaber konflikter i den videre process, jvf.afsnit "Patch af komponenter".

2.2 Patch af komponenter

I forbindelse med QA af komponenter vil NSP Leverandøren kunne have behov for at levere ændringer til komponenten tilbage til Komponentleverandøren. Det kan eksempelvis være en rettelser til konfigurationen for at kunne håndtere ændringer i NSP platformen, eller (typisk) mindre koderettelser. Komponentleverandøren skal altid godkende rettelsen, og dermed sikre at den fremover vil være med i nye leverancer (se Husregler for udvikling til NSP old).
Rent praktisk kan et patch af en komponent foregå på flere måder. Det afhænger af omstændighederne og der stilles derfor intet krav om på, hvilken form en ændring til en komponent skal tilflyde Komponenetleverandøren. Det må afgøres fra sag til sag, hvad der er hensigtsmæssigt. (Se endvidere Husregler for udvikling til NSP old).

3 Driftsleverance

Ved en driftsleverance forstås en aftalt overdragelse af en specifik komponentversion fra NSP leverandøren til NSP driftsleverandøren med henblik på idriftssættelse af denne.

3.1 NSP leverance

Efter at have foretaget individuel byg og test af de enkelte komponenter og integration på den relevante NSP platform, afleveres en NSP leverance fra NSP Leverandør til NSP Driftsleverandør, som indeholder, men ikke er begrænset til:

  • Binære komponenter
  • Konfiguration af komponenter (og deres afhængigheder)
  • Stamdata
  • Testvejledninger
  • Testresultater
  • Testdata

NSP leverancen placeres i SVN. Layoutet er defineret som vist på Figur 2. Her ses opdeling mellem test og release i trunk. Test-området er struktureret i test-aspekter og kandække en enkelt komponent eller gå på tværs af komponenter. Det er fuldstændig styret af, hvordan komponenter opererer i problemområdet og dermed kan indholdet af aspekter variere. Release-området er struktureret pr. komponent og hver komponentområde indeholder det artefakt,
som udgør komponenten.

Figur 2: NSP Leverandørens SVN område

4 Patch af NSP leverance

NSP Driftsleverandør modtager den kvalitetssikrede NSP leverance. Ifbm. overdragelse kan der forekomme situationer, som kræver ændringer i det leverede. Oplysninger om hvad der bør rettes skal tilgå NSP Leverandør ad sædvanlige kommunikationskanaler og/eller sagsstyringsværktøj.

Her kan eksempelvis være tale om ændringer til kode eller binære artefakter. NSP Leverandøren skal herefter afgøre, hvorvidt der er tale om en simpel eller kompleks ændring og enten udføre ændringen selv eller lade Komponentleverandøren udføre ændringen. Ved simple ændringer udført af NSP Leverandøren skal ændringen flyde tilbage til Komponentleverandøren på samme måde som beskrevet i afsnit "Patch af komponenter". Simple ændringer kan sandsynligvis udføres uden en ny komponentleverance.

Ved komplekse ændringer informeres Komponenetleverandøren af NSP Leverandøren om ændringen der skal udføres, hvorefter Komponenetleverandøren godkender og udfører ændringen. Komplekse ændringer er kun med i upstream-releases.

4.1 Illustreret leveranceprocess


Figur 3: Leveranceprocess