Bilaga om livscykelhantering för SDK

Anslutning för deltagarorganisationer
Sidkod: A1.5.3
Version: 1.5

Sammanfattande principer för livscykelhantering av dokument inom SDK-federationen med beskrivning av hantering av support, problem- och felhantering samt incidenthantering.

1. Inledning

En definierad och överenskommen livscykelhantering är viktig både för att SDK:s specifikationer och dokumenttyper ska kunna utvecklas över tid och tillgodose utvecklingsbehov, och för att deltagarorganisationer ska kunna planera för interna förvaltningsaktiviteter och anpassning av de anslutande system som tillämpar specifikationerna.

SDK:s livscykelhantering reglerar SDK regelverk, tekniska specifikationer och gemensamma komponenter (SDK adressbok och SDK testklient). Livscykelhanteringen beskriver olika typer av förändringar, processen för förändring samt regler för förändring (hur deltagarorganisation ska förhålla sig till/följa ändringen).

För att uppnå ett stabilt och kontinuerligt meddelandeutbyte mellan deltagarorganisationer behövs därför gemensamma principer för hur specifikationerna förändras över tid och kan samexistera.

Över tid finns det behov av att stödja:

  • Hur befintliga specifikationer och meddelanden (meddelandetyper/dokumenttyper) kan förändras och utvecklas.
  • När nya specifikationer och meddelanden (meddelandetyper/dokumenttyper) kan tillkomma.
  • När specifikationer och meddelanden (meddelandetyper/dokumenttyper) kan behöva avvecklas
  • Förändringar i SDK-federationens gemensamma komponenter (SDK adressbok och SDK testklient).

2. Aktuella versioner

Aktuella versioner av dokument framgår av Regelverk för deltagarorganisationer.

2.1 Typer av release

Varje release för styrande dokumentation inom SDK samt vissa stödjande dokument (t ex rekommendationer) representeras av tre olika release-typer; major/stor, minor/mellan och subminor/liten.

Release-typ

Beskrivning

Major (1.0)

  • En ”major-version” representeras av den första siffran i versionsnumret. Den ändras när det släpps en betydande ändring av ramverkets beståndsdel. En ny majorversion indikerar oftast strukturändringar som tekniskt bedöms påverka kompatibilitet med tidigare versioner och stora nya funktioner eller krav.
  • T ex när ett fält blir obligatoriskt.
  • En majorversion medför att deltagarorganisationens meddelandeklient, meddelandetjänst eller accesspunkt påverkas och behöver anpassas.

Minor (1.1)

  • En ”minor-version” representeras av den andra siffran i versionsnumret. Den ändras när mindre förbättringar eller nya funktioner läggs till utan att bryta kompatibilitet med tidigare versioner.
  • T ex när ett nytt frivilligt fält har tillkommit där verksamheten inte bedöms påverkas av förändringen.

Subminor (1.0.1)

  • En ”subminor-version” representeras av den tredje siffran i versionsnumret. Endast mindre uppdateringar, rättelser och buggfixar. Dessa uppdateringar syftar till att förbättra stabilitet och tydlighet i ramverkets beståndsdelar.

2.2 Principer för utveckling och förvaltning av funktionalitet och regelverket för SDK

Följande principer gäller:

  • Federationsägare SDK beslutar och godkänner ny funktionalitet som t ex nya meddelandetyper och specifikationer i form av major-/minorrelease och informerar samtliga anslutna via releaseinformation.
  • Samverkansforum för utveckling och möjlighet att bidra med önskemål och förbättringsförslag erbjuds alla aktörer.
  • Behovsdriven utveckling gäller för teknisk funktionalitet samt förändrat regelverk där behoven tydligt skall framgå för önskad utveckling. Utveckling beslutas och styrs av federationsägaren för SDK och sker sedan i samverkan med deltagarorganisationerna och aktörer anslutna till SDK
  • Ny funktionalitet alternativt en ny release innehåller alltid en beskrivning av ändringen utifrån ett verksamhets- eller tekniskt perspektiv beroende på förändringens omfattning.
  • Federationsägare SDK beslutar och ansvarar för produktionssättning av ny funktionalitet och regelverk enligt gällande releasehantering SDK.
  • Federationsägare SDK beslutar och ansvarar för anslutningshantering och breddinförande inom SDK med olika förfaranden beroende på ny funktionalitet och regelverk enligt gällande anslutningsförfaranden och deklaration av följsamhet inom SDK.
  • Releasehantering SDK omfattar även gemensamma komponenter (SDK adressbok och SDK testklient) som ingår i SDK.

2.3 Hantering av flera samtidiga versioner av meddelandetyper och övriga styrande specifikationer

Hantering av flera samtidiga major-versioner av SDK:s meddelandetyper och övriga styrande specifikationer för deltagarorganisationer och leverantörer av meddelandesystem specifikationer sker enligt följande principer:

Meddelandetyper:

  • I huvudsak kommer endast major-versioner att släppas för en meddelandetyp. Det kan finnas flera meddelandetyper i SDK-federationen.
  • I undantagsfall kan minor-versioner användas efter beslut av federationsägaren.
  • Vid release av en ny version av en meddelandetyp kommer två major-versioner att vara aktiva parallellt i produktionsmiljö under en viss period.
  • Om det uppstår ett akut behov av en ny major-version kan denna produktionssättas och därmed kan antal samtidiga major-versioner utökas.
  • Upp till tre major-versioner av en meddelandetyp kan vara aktiva i SDK testmiljöer (omfattar ej akut major-version). SDK-federationsägare tillhandahåller en SDK QA-miljö som är produktionslik (dock: endast testdata får förekomma) och som också tillåter tester av nyare versioner.
  • En version av en meddelandetyp som är markerad som ”utgången” får inte användas längre.

Övriga specifikationer:

  • Hantering av major-versioner:
    • Major-versioner släpps vid behov
    • Vid release av ny specifikation kan två major-versioner vara aktiva samtidigt i produktionsmiljö under en viss tidsperiod. Federationsägaren beslutar om detta från fall till fall.
    • Vid flera aktiva major-versioner kan dessa vara aktiva i SDK testmiljöer (omfattar inte akut major-version).
  • Minor-versioner släpps löpande vid behov.
  • En specifikation som är markerad som ”utgången” får inte användas längre.

2.4 Releasehantering för meddelandetyper och specifikationer

Följande regler gäller för stegning av version för deltagarorganisationer:

  • Deltagarorganisationer förbinder sig att (SKA) följa fastställd releasehantering för meddelandetyper och specifikationers livscykel.
  • Deltagarorganisationer förbinder sig att (SKA) stödja en ny major-version av meddelandetyp och specifikation senast 12 månader efter att release är fastslagen i produktion om ej annat beslutas från federationsägare.
  • Deltagarorganisationer BÖR stödja två versioner av meddelandetyper och specifikationer i produktionsmiljö.
    • SKA stödja: den version som är obligatorisk* version, dvs. tidigare (lägre) version (t.ex. 1.0)
    • BÖR stödja: senaste aktuell version (t.ex. 2.0)
      *Obligatorisk version är den version som alla deltagarorganisationer måste stödja vid anslutning till SDK-federationen.
  • Deltagarorganisation anmäler stöd för ny version till SDK-federationsägare via självdeklaration.
Hjälpte denna information dig?

Ditt svar hjälper oss att förbättra sidan

Senast uppdaterad: