Jämförda versioner

Nyckel

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


 

Konfigurationsstyrning tjänstedomäner


Version 2.2.89

ARK_0007


2022-0612-1407



Innehållsförteckning


Revisionshistorik

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
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
2.2.62019-12-11Ändrat skrivningar kring ändring av domängemensamma scheman, tagit bort skrivning om hur version i filnamn påverkas eftersom detta ska beskrivas på annan platsBjörn Hedman
2.2.72020-01-30Ändrat och kompletterat kapitel 2 för att förtydliga mot nuvarande process för ny- och vidareutveckling av tjänstekontrakt.

Ranjdar Fallyih

Claudia Ehrentraut

2.2.82022-05-06

Textuella uppdateringar för att öka tydligheten i dokumentet.

Bytt ut Arkitektur och Regelverk mot Inera Arkitektursektion.

Lagt till information om hur JoL-headern ska refereras till i berörda tjänstekontrakt.

Lagt till ett exempel på hur olika ändringar påverkar versionering

Flyttar information om versionering från Appendix till avsnitt 3

Tobias Blomberg

Anneli Duveborg

2.2.92022-12-07

Tagit bort information om byggskript då dessa ej ska inkluderas i domänpaketeringen framöver.

Lagt till bildtexter

Tobias Blomberg

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 

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.

...

En tjänstedomänsversion utrycks med siffror i en två eller treställig kombination

Ex 2.1 eller 2.1.1

En

tjänstedomän Figur 1. Beskrivning av versionering av tjänstedomän.


En tjänstedomän kan alltså innehålla tjänstekontrakt med olika versionsnummer.  Grundregeln för versionsnumrering är att tjänstedomänens major & minor-version ska motsvara den högsta versionen på något av de ingående tjänstekontrakten. Till detta kommer en tredje siffra som räknas upp vid all annan förändring.

...

clinicalprocess:healthcon:actoutcome  4.0.2clinicalprocess:healthcon:actoutcome  4.0.2
GetLaboratoryOutcome 4.0GetLaboratoryOutcome 4.0
GetReferralOutcome 3.1GetReferralOutcome 3.0
GetImagingOutcome 1.0GetReferralOutcome 3.1
GetMaternityMedicalHistory 2.0GetImagingOutcome 1.0

GetMaternityMedicalHistory 2.0

...

Typer som används i flera tjänstekontrakt 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:

...

Om ett nytt Git-repository ska skapas för aktuell tjänstedomän på Bitbucket, behöver du själv initiera denna och skapa nödvändig katalogstruktur. Alla tjänstedomäner ska följa en gemensam och fastställd filstruktur. Denna struktur och namnstandard är inkorporerad i script och måste därför strikt följas.

Exempel:

Info
iconfalse

Image Removed

code_gen

I ”code_gen”-katalog ska det finnas bygg-script för att generera kod från WSDL-filerna, som stöd för utveckling av tjänstekonsumenter och tjänsteproducenter (se avsnitt 2.2.2). Underkataloger till code_gen ska skapas för Javaplattformens standard (JAX-WS) och .Net.

Exempel:

Image Removed

Image Added
Figur 2. Filstruktur i tjänstedomän.


docs

I "docs"-katalogen finns tjänstekontraktsbeskrivning (TKB), informationsspecifikation (IS), arkitekturella beslut (AB) och självdeklarationer. Om något eller några tjänstekontrakt i domänen använder JoL-headern, ska denna katalog även innehålla fältregeldokument för de versioner av JoL-headern som används i domänen.

...

  • TKB_ <tjänstedomännamn>.docx, ex TKB_clinicalprocess_activityprescription_actoutcome.docx
  • AB_ <tjänstedomännamn>.docx, ex AB_clinicalprocess_activityprescription_actoutcome.docx
  • IS_<tjänstedomännamn>.docx, ex IS_clinicalprocess_activityprescription_actoutcome.docx
  • SjD_TK_<tjänstekontraktsnamn>.docx, ej obligatoriskt

Exempel:

Figur 3. Filstruktur i mappen docs.


Schemas

WSDL:er och scheman ordnas i katalogen ”schemas”. I ”schemas” ska två underkataloger finnas: ”core_components”, och ”interactions”.

Exempel:

Figur 4. Filstruktur i mappen schemas

  • ”core_components” innehåller scheman som är generella för domänen (t.ex. domän-scheman och header-scheman)
  • ”interactions” innehåller en underkatalog per tjänstekontrakt. I dessa ska schema och WSDL ligga som är specifika för respektive tjänstekontrakt.
  • "engagementindex" (ej obligatorisk) innehåller verktyg för validering av de delar av schemat som används av engagemangsindex.

...

Nedan figur visar ett exempel på hur olika typer av ändringar påverkar versioneringen av tjänstekontrakt och tjänstedomäner. Kolumnen Ändring visar vilken typ av ändring som skett i domänen med en streckad linje till tjänstekontraktet i vilket förändringen skett. Sista kolumnen redovisar utfallet på domänversionen baserad på den aktuella förändringen.

Figur 5. Flöde över versionering av tjänstedomän.


Expandera
titleTextuell beskrivning av domänversionering

NOTERA: Även fast tjänstedomäner kan ha samexisterande tjänstekontrakt men olika huvudversioner (Major) så kan dessa av tekniska skäl inte paketeras tillsammans givet hur installationsskripten fungerar (baserat på hur man gjort historiskt) så därför måste tidigare huvudversioner tas bort ur taggningen för en viss version. Domäner som har tjänstekontrakt i flera olika huvudversioner kan därför behöva ha flera samtidiga paketeringar som är publicerade

Exempel 1

  • Tjänstekontrakt A 1.0
  • Tjänstekontrakt B 1.1
  • Tjänstedomän 1.1

Exempel 2

  • Tjänstekontrakt A 1.0
  • Tjänstekontrakt B 2.0
  • Tjänstedomän 2.0

Uppdatering av major och/eller minor

Vissa förändringar av ingående tjänstekontrakt innebär att tjänstedomänens major och/eller minor ska uppdateras.

Exempel 1 - Bakåtkompatibel ändring av kontrakt, ny minor nu högst

  • Före ändring
    • Tjänstekontrakt A 1.0
    • Tjänstekontrakt B 1.1
    • Tjänstedomän 1.1
    • Efter ändring
      • Tjänstekontrakt A 1.0
      • Tjänstekontrakt B 1.2
      • Tjänstedomän 1.2

Exempel 2 - Icke bakåtkompatibel ändring av kontrakt, ny major och minor nu högst

  • Före ändring
    • Tjänstekontrakt A 2.0
    • Tjänstekontrakt B 2.3
    • Tjänstedomän 2.3
    • Efter ändring
      • Tjänstekontrakt A 3.0
      • Tjänstekontrakt B 2.3
      • Tjänstedomän 3.0

Lägga till/uppdatera tredje siffra

Andra förändringar innebär inte att domänens major och/eller minor ska uppdateras. I dessa fall används en tredje siffra i domänens versionsnummer. Den tredje siffran läggs till, alternativt räknas upp. Den första tredje siffran som används är alltid 1.

Exempel 1 - Dokumentationsuppdatering, ingen förändring av kontrakt, tredje siffra läggs till

  • Före uppdatering
    • Tjänstekontrakt A 1.0
    • Tjänstekontrakt B 1.1
    • Tjänstedomän 1.1
    • Efter uppdatering
      • Tjänstekontrakt A 1.0
      • Tjänstekontrakt B 1.1
      • Tjänstedomän 1.1.1

Exempel 2 - Bakåtkompatibel ändring av kontrakt, nuvarande major och minor fortfarande högst, tredje siffra läggs till

  • Före ändring
    • Tjänstekontrakt A 1.1
    • Tjänstekontrakt B 2.0
    • Tjänstedomän 2.0
    • Efter ändring
      • Tjänstekontrakt A 1.2
      • Tjänstekontrakt B 2.0
      • Tjänstedomän 2.0.1


Exempel 3 - Ett helt nytt tjänstekontrakt tillkommer i en befintlig domän, nuvarande major och minor fortfarande högst, tredje siffra läggs till

  • Före ändring
    • Tjänstekontrakt A 1.1
    • Tjänstekontrakt B 2.0
    • Tjänstedomän 2.0
    • Efter ändring
      • Tjänstekontrakt A 1.2
      • Tjänstekontrakt B 2.0
      • Tjänstekontrakt C 1.0
      • Tjänstedomän 2.0.1

Exempel 4 - Icke bakåtkompatibel ändring av kontrakt, nuvarande major och minor fortfarande högst, tredje siffran används redan så denna räknas då upp.

  • Före ändring
    • Tjänstekontrakt A 1.4
    • Tjänstekontrakt B 2.2
    • Tjänstedomän 2.2.1
    • Efter ändring
      • Tjänstekontrakt A 2.0
      • Tjänstekontrakt B 2.2
      • Tjänstedomän 2.2.2

...