Versions Compared

Key

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

Table of Contents
maxLevel2

 

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.

Table of Contents
maxLevel2

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:

...

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

...

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:

...

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