Versions Compared

Old Version 3

changes.mady.by.user Unknown User (sdh)

Saved on

compared with

New Version 4

changes.mady.by.user Unknown User (sdh)

Saved on

Key

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

...

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

  • Kildekode, inkl. test1test (Husregler 1.0, §2.4.2 og §2.4.3)
  • Stamdata
  • Testdata eller instrumenter til at skabe testdataDokumentation2
  • 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) 3(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 arkiv4arkiv (.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.1 se Husregler 1.0, §2.4.2 og §2.4.3
2 se Husregler 1.0, §2.4.1
3 se http://svnbook.red-bean.com/en/1.7/svn.tour.importing.html#svn.tour.importing.layout

Image Added

4 .zip, .gz, .tar, .jar, .war, .ear etc
Version: 0.1 Side 3 of 7
Figur 1: NSP respository, standard SVN layout
SVN anvendelse
NSP

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

Patch af komponenter

...

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 2.2. 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.3.3

Illustreret leveranceprocess


Figur 3: Leveranceprocess