Jämförda versioner

Gammal version 13

changes.mady.by.user Ranjdar Fallyih

Sparat den

jämfört med

Ny version 14

changes.mady.by.user Björn Hedman

Sparat den

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.


 

Konfigurationsstyrning tjänstedomäner


Version 2.2.45

ARK_0007


2019-0312-1304



Innehållsförteckning


Utgåvehistorik för dokumentet

Rev. Nr

Rev. Datum

Beskrivning av ändringar

Ändringarna gjorda av

1.0

2012-01-03

RIVTA Konfigurationsstyrning 1.0


2.0

2013-10-29

Handledning konfigurationsstyrning 2.0


2.0.1

2014-01-30

Uppdatera exempel för namnsättning av TAG-namn


2.0.2

2014-02-11

Flyttade test-suite till rätt plats i mappstrukturen.

Förtydligade namnsättningsreglerna för TKB och AB.

Ändrade ”ServiceContracts” till ”ServiceInteractions” i sökväg till domänerna.


2.0.3

2014-02-20

Förtydligande av krav och hantering av release av Tjänstedomän.


2.0.4

2014-06-04

Fixade typo i exempel av namnsättning av tjänstedomän (ändrade ”Clinicalprocess….” till ”clinicalprocess….”.

Byte till Inera-mall.


2.0.5

2014-06-30

Ersatte alla referenser till ”CeHis” med ”Inera”.


Tog bort alla referenser till självdeklaration av följsamhet.


Fixade enstaka typos.


Ändrade namnsättningsregeln för TKB och AB. Dessa skall inte längre ha versionsbeteckning i filnamnet.


Förtydliga mappstrukturen och kravet på en undermapp per intraktion (WSDL-fil).


Förtydliga versionreglerna. Tredje versionstalet uppstår endast efter den första dokumentationsuppdateringen och kan därför aldrig vara 0.


Förtydliga att Inera Arkitektur och regelverk skapar zip-filerna vid release.


Förtydliga att en tag alltid skapas mha kommandot ”svn copy”.

Adderade Bilaga 5 som beskriver hur en tjänstedomän byter namn (namnrymnd).


2.0.6

2014-08-07

Förtydligade att en release skall ske baserat på en godkänd RC, inte från trunk.


2.0.7

2014-10-07

Endast redaktionella ändringar samt ny label på WEB.


2.0.8

2015-05-20

Beskrivning av den nya hanteringen som innebär att inga RC produktionssätts.


2.1

2015-06-17

Anpassat instruktionen till Bitbucket och Git.

Tagit bort Bilaga 1 ”Checka ut källkodsrepository” då den inte längre gäller.

Tagit bort Bilaga 4 ”Skapa Release-tag” pga att det skiljer sig mellan olika verktyg. Hänvisar istället till http://rivta.se/bitbucket

Tagit bort Bilaga 5 ”Namnbyte av tjänstedomän”, då den beskrev ett Subversion-specifikt förfarande.


2.1.1

2015-12-17

Rättat uppgifter om var anvisning om testsvit hittas och var dessa skall placeras i katalogstrukturen.

Lagt till information om korrekt namn på dokumentet Informationsspecifikation.

Förändrat namngivning av tags.


2.2

2016-10-18

Ändrat språkliga fel och gjort en del förtydliganden

Rensat ordlista på begrepp som inte är specifika för detta dokument

Ändrat till att genomgående använda begreppen tjänstekonsument och tjänsteproducent

Lagt till att verktyget Python behövs

Lagt till rollen Tjänsteansvarig

Bytt ”Bilaga” till ”Appendix”.

Förtydligat att alla nya tjänstedomäner ska använda den nya formen för namngivning av en tag

Kompletterat och förtydligat versionsnumrering i Appendix 2.

Definitioner av begreppen fastställd release och ändringsfryst

Ändrade uttrycket formell release till fastställd i texten

Beskrivning av ”frysningskonceptet”

Lagt till steget RIVTA Verifiering

Förtydligat att allt innehåll ska ingå i varje release av en domän


2.2.1

2016-11-09

Ändrat uppgifter om var man ska kontakta till (kundservice@inera.se).


2.2.22018-10-01

Lagt till förtydligande gällande versionering av tjänstekontrakt som tillkommer i befintlig tjänstedomän

Uppdaterat exempel kring domänversionering med major.minor och tredje siffra

Lagt till kolumn i utgåvehisstorik (ändringarna utförda av)

Lagt till avsnitt kring versionshantering av gemensamma scheman

Lagt till förtydligande kring hur siffrorna i versionsnumrering ska användas

Björn Hedman
2.2.32019-03-06Bytt ”Bilaga” till ”Appendix”.Ranjdar Fallyih
2.2.42019-03-13

Ändrat exempel för paketering i Appendix A så att dessa återspeglar hur installationsskripten hanterar paketering.

Förtydligat att en viss paketering inte kan innehålla flera huvudversioner av samma tjänstekontrakt även om det finns flera som är giltiga för domänen

Björn Hedman

Ordlista

...

Ord som används i dokumentet

...

Beskrivning

...

Konfigurationsstyrning/ konfigurationshantering

...

Konfigurationsstyrning används för att identifiera versioner, komponenters utvecklingsstatus och ändringar.

För att underlätta hanteringen, genom att enkelt kunna identifiera och spåra olika versioner används automatiserade verktyg för versionshantering.

...

Version

...

Tjänstekontrakt kan ha olika utgåvor. Varje utgåva benämns version och ska ha en versionsbeteckning.

...

Release

...

När en ny version av den slutgiltiga tjänstedomänen paketerats och är fastställd benämns den Release.

...

Release Candidate (RC)

...

När en version av en tjänstedomän har paketerats och är klar att testas/verifieras benämns den Release Candidate

...

Fastställd release

...

Den release man beslutat gå i produktion med. Efter genomförda regressionstester i QA/SIT är releasen färdig för installation i PROD 

...

Ändringsfryst

...

Någon av de parter som medverkar i framtagandet av en ny release har fått ensamrätt till att införa ändringar och be om nya RC. Se mer utförlig beskrivning i sektion 2.7

...

Git

...

Automatiserat verktyg för versionshantering. https://git-scm.com/

...

RIVTA Källkodsrepository

...

Ett centralt register (repository) för att samla och spara tjänstedomänens artefakter och göra dem sökbara genom att märka upp (tagga) dem.

Referenser

Här finns källkod och dokumentation för alla nationella tjänstedomäner.

Varje tjänstedomän har dessutom en ärendehantering, avsedd för buggrapporter och ändringsförslag

Namn

Kommentar

Länk

RIVTA tjänstedomäner

Här finns alla nationella tjänstedomäner listade, tillsammans med dess tjänstekontrakt releaser, och granskningsstatus.

http://rivta.se/domains

RIVTA dokument

Här finns länkar till T-boken, RIV tekniska anvisningar samt mallar och anvisningar för SAD, tjänstekontraktsbeskrivning och arkitekturella beslut (AB)

http://rivta.se/documents

Bitbucket

2.2.52019-12-04

Förtydligat att utvecklingen av nya tjänstekontrakt eller nya versioner av kontrakt måste göras med en konsument och en producent

samt att versionen ska ha testats i en teknisk leverans för konsument och producent innan fastställande sker (Kapitel 2)

Rättat exempel kring hantering av schemafiler i core_components (och ändrat från common objects till just core_components)

Björn Hedman

Ordlista

Ord som används i dokumentet

Beskrivning

Konfigurationsstyrning/ konfigurationshantering

Konfigurationsstyrning används för att identifiera versioner, komponenters utvecklingsstatus och ändringar.

För att underlätta hanteringen, genom att enkelt kunna identifiera och spåra olika versioner används automatiserade verktyg för versionshantering.

Version

Tjänstekontrakt kan ha olika utgåvor. Varje utgåva benämns version och ska ha en versionsbeteckning.

Release

När en ny version av den slutgiltiga tjänstedomänen paketerats och är fastställd benämns den Release.

Release Candidate (RC)

När en version av en tjänstedomän har paketerats och är klar att testas/verifieras benämns den Release Candidate

Fastställd release

Den release man beslutat gå i produktion med. Efter genomförda regressionstester i QA/SIT är releasen färdig för installation i PROD 

Ändringsfryst

Någon av de parter som medverkar i framtagandet av en ny release har fått ensamrätt till att införa ändringar och be om nya RC. Se mer utförlig beskrivning i sektion 2.7

Git

Automatiserat verktyg för versionshantering. https://git-scm.com/

RIVTA Källkodsrepository

Ett centralt register (repository) för att samla och spara tjänstedomänens artefakter och göra dem sökbara genom att märka upp (tagga) dem.

Referenser

Namn

Kommentar

Länk

RIVTA tjänstedomäner

Här finns alla nationella tjänstedomäner listade, tillsammans med dess tjänstekontrakt releaser, och granskningsstatus.

http://rivta.se/source

1                Inledning

...

domains

RIVTA dokument

Här finns länkar till T-boken, RIV tekniska anvisningar samt mallar och anvisningar för SAD, tjänstekontraktsbeskrivning och arkitekturella beslut (AB)

http://rivta.se

...

/documents

Bitbucket

Här finns källkod och dokumentation för alla nationella tjänstedomäner.

Varje tjänstedomän har dessutom en ärendehantering, avsedd för buggrapporter och ändringsförslag.

http://rivta.se/source


1                Inledning

Detta är en handledning gällande hur tjänstedomäner ska lagras, versionshanteras och releasas på RIVTA (http://rivta.se). Dokumentet innehåller också instruktioner för framtagning av de utvecklingshjälpmedel (”byggfiler”) för Microsoft .Net och Java-plattformen som ska medfölja en release av en tjänstedomän. RIVTA ägs och förvaltas av Inera Arkitektur och Regelverk.

...

Länkar till regelverk, mallar och exempel som ligger till grund för denna handledning finns på:

http://rivta.se/documents.

2               Skapa ny release av en tjänstedomän

och exempel som ligger till grund för denna handledning finns på:

http://rivta.se/documents.


2               Skapa ny release av en tjänstedomän

Förtydligande:

Utvecklingen av nya tjänstekontrakt eller nya versioner av befintliga tjänstekontrakt ska ske i samarbete mellan MINST en producent och en konsument och SKA acceptanstestas i en teknisk leverans av konsument och producent kod mellan dessa innan granskning.

Om den/de nya versionerna är minor versioner så SKA de även testas för bakåtkompabilitet. Om det inte finns tillgång till testmiljöer för verkliga konsumenter och producenter för dessa tester så kan testsviter användas istället (se också kapitel 2.7)

Gången är i korthet följande:

  • Vid utveckling av tjänstekontrakt arbetar projektet iterativt i Git med olika versioner.
  • När projektet har en version, release candidate (RC), som är klar för granskning görs en begäran till Inera Arkitektur och regelverk om kvalitetssäkring
  • Projektet fortsätter sitt arbete och kan vid behov leverera ytterligare RC för granskning .
  • Då projektet har testat en version (normalt är detta en release candidate) som man beslutat tillämpa i produktion gör projektet en begäran till Inera Arkitektur och Regelverk om att skapa en fastställd release

...

Typer som används i flera interaktioner kan deklareras i en eller flera domängemensamma schemafiler som placeras i katalogen /schemas/core_components/

Vid behov av förändringar och tillägg av gemensamma typer behöver följande beaktas:

...

  • Före uppdatering
    • Tjänstekontrakt A 1.0
    • Tjänstekontrakt B 1.1
    • CommonCore_Objectscomponents
      • DomainSchema1.0
    • Tjänstedomän 1.1
    • Efter uppdatering
      • Tjänstekontrakt A 1.0
      • Tjänstekontrakt B 1.1
      • Tjänstekontrakt C 1.0
      • Tjänstekontrakt D 1.0
      • CommonCore_Objectscomponents
        • DomainSchemaProfession1.0
        • DomainSchema1.0
      • Tjänstedomän 1.1.1

Om det senare behövs ytterligare förändringar kring dessa nya typer kan DomainSchemaProfession sättas till 1.1 eller 2.0 (beroende på förändringens karaktär) och importeras i tjänstekontrakten C & D som i sin tur versioneras utifrån om förändringen är bakåtkompatibel eller ej.

...

  • Tjänstekontrakt A 1.0
  • Tjänstekontrakt B 1.1
  • CommonCore_Objectscomponents
    • DomainSchema1.0
  • Tjänstedomän 1.1
  • Efter uppdatering
    • Tjänstekontrakt A 1.1
    • Tjänstekontrakt B 1.2
    •  Common Core_Objectscomponents
      • DomainSchema1.1
      • DomainSchema1.1_ext

...