7. januar 2014. Serviceplatformen 1. Release- og Versioneringsstrategi for Serviceplatformen og services Nærværende notat beskriver Serviceplatformens Release- og Versioneringsstrategier. Formålet med disse strategier er at fastlægge hvorledes nye udgaver af Serviceplatformen og de services, der udstilles på Serviceplatformen, udrulles i drift, således at kompatibiliteten mellem Serviceplatformen og anvendersystemer er veldefineret. Det præciseres, at ændringer som følge af lovvedligehold kan være underlagt konkrete regler for, hvornår ændringerne skal være idriftsat. Hvor det er muligt, anbefales det at retningslinjerne i nærværende dokument følges. 2. Releasestrategi for Serviceplatformen Releasestrategien for Serviceplatformen skal sikre at nye udgave af Serviceplatformen kan idriftsættes forsvarligt. Serviceplatformen udgør fundamental infrastruktur i den Fælleskommunale Rammearkitektur. Anvendersystemer må ikke efter en udrulning af en ny udgave af Serviceplatformen efterlades uden at kunne anvende denne. Serviceplatformens miljøer Serviceplatformen er idriftsat i to eksternt tilgængelige miljøer: Produktionsmiljøet, der indeholder den kørende Serviceplatform med produktionsdata. Eksternt Testmiljø, der indeholder en Serviceplatform til testformål der kan anvendes af leverandører og kommuner, uden produktionsdata. Disse miljøer indgår i releasestrategien for Serviceplatformen. Strategien Releasestrategien for Serviceplatformen styres af definitionen af versioneringsstrategi og kompatibilitet, jf. afsnit 4. Ved leverandører i nedenstående forstås både it-leverandører, samt kommuner der selv vedligeholder og videreudvikler kommunale it-systemer. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/9
Releasestrategien er som følger: Ved ændringer der korrigerer fatale fejl eller sikkerhedsmæssige fejl eller mangler opdateres Produktionsmiljøet og det Eksterne Testmiljø umiddelbart, enten jf. servicevinduer i driften eller umiddelbart efter aftale med driftsgruppen. Ved en ændring der kun kræver ny Micro version, opdateres Produktionsmiljøet og det Eksterne Testmiljø umiddelbart, jf. servicevinduer i driften. Det Eksterne Testmiljø kan opdateres i et forudgående servicevindue. Ved en ændring der kræver ny Minor version, opdateres det Eksterne Testmiljø med den nye version mindst 1 kalendermåned før Produktionsmiljøet. Ved en ændring der kræver ny Major version: a) Såfremt optionen på den Decentrale Serviceplatform (DSP) er udnyttet, frigives en udgave af DSP svarende til den nye version af Serviceplatformen mindst 3 kalendermåneder inden den nye Serviceplatform idriftsættes. Denne udgave gøres tilgængelig for leverandører og kommuner. b) Såfremt optionen på DSP IKKE er udnyttet, etableres et nyt midlertidigt Eksternt Testmiljø mindst 3 kalendermåneder forud for idriftsættelse af den nye Serviceplatform. Den nye version af Serviceplatformen idriftsættes heri, og der gives adgang til interesserede kommuner og leverandører. c) Uanset tilstedeværelsen af DSP, opdateres det Eksterne Testmiljø med den nye version mindst 1 kalendermåned før Produktionsmiljøet. Såfremt der er etableret et midlertidigt Eksternt Testmiljø jf. b) kan dette herefter nedlægges. Samtidige versioner Releasestrategien for Serviceplatformen understøtter 1 version af Serviceplatformen i Produktionsmiljøet, og 1 (evt. alternativ) version i det Eksterne Testmiljø. Den generelle regel er, at det Eksterne Testmiljø vil være lig med eller 1 version nyere end Produktionsmiljøet. Advisering af nye versioner til leverandører af anvendersystemer Ved introduktion af en ny version, eller når en eksisterende version skal elimineres, skal leverandørerne af anvendersystemerne adviseres. Principperne for advisering om nye versioner er som følger: Ændringer til Serviceplatformen, der kræves udrullet grundet rettelser af fatale fejl eller sikkerhedsrelaterede fejl eller mangler, foretages af KOMBIT uden foregående advisering. Efter opdatering adviseres generelt via nyheder om Serviceplatformens driftsstatus. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 2/9
Ændringer der udelukkende resulterer i en positiv ændring af versionens Build nummer eller Micro nummer, eller en negativ ændring i versionens Build nummer, foretages af KOMBIT uden foregående advisering, da der per definition ingen negative konsekvenser er for anvendersystemer. Efter opdatering adviseres generelt via nyheder om Serviceplatformens driftsstatus. Ændringer der resulterer i en positiv ændring af versionens Minor nummer, eller en negativ ændring i versionens Micro nummer, foretages af KOMBIT efter en generel advisering af leverandører af anvendersystemerne, med mindst 1 kalendermåneds varsel. Konsekvenserne for Anvendersystemer bør være minimale. Det pointeres at dette samtidig er en eliminering af den tidligere kompatible version. Ændringer der resulterer i en ændring af versionens Major nummer, eller en negativ ændring af versionens Major eller Minor nummer (dvs. rollback), foretages først af KOMBIT efter konkret advisering af leverandørerne for alle involverede anvendersystemer. Der adviseres med mindst 3 kalendermåneders varsel ved en ny Major version, og med så lang varsel som muligt ved rollback. Advisering skal generelt tage højde for perioder med mindre fokus såsom ferieperioder, hvor adviseringsfrister bør regnes EFTER perioden er afsluttet, dvs medio august for sommerferiens vedkommende, i stedet for ultimo juni. 3. Releasestrategi for services udstillet af Serviceplatformen Releasestrategien for services udstillet af Serviceplatformen skal sikre at anvendersystemer fortsat kan kalde eksisterende services i en veldefineret overgangsperiode, når en ny version introduceres i Serviceplatformen. Releasestrategien skal understøtte udbygningen af serviceplatformen ved at lette administration i forbindelse med services livscyklus: Tilføjelse af nye services Rettelser til services (f.eks. fejlrettelse) Nye versioner (f.eks. ny snitflade) Fjernelse af services Serviceplatformen understøtter multiple versioner af de udstillede services, hvorfor det er muligt at give anvendersystemer en brede understøttelse af gamle versioner. Serviceplatformens miljøer indgår i releasestrategien for services udstillet af Serviceplatformen. Strategien KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 3/9
Releasestrategien er som følger: Ved ændringer der korrigerer fatale fejl eller sikkerhedsmæssige fejl eller mangler opdateres Produktionsmiljøet og det Eksterne Testmiljø umiddelbart, enten jf. servicevinduer i driften eller umiddelbart efter aftale med driftsgruppen. Ved en ændring der kun kræver ny Micro version, opdateres Produktionsmiljøet og det Eksterne Testmiljø umiddelbart, jf. servicevinduer i driften. Det Eksterne Testmiljø kan opdateres i et forudgående servicevindue. Ved en ændring der kræver ny Minor version, opdateres det Eksterne Testmiljø med den nye version mindst 10 kalenderdage før Produktionsmiljøet. Ved en ændring der kræver ny Major version, opdateres det Eksterne Testmiljø med den nye version mindst 1 kalendermåned før Produktionsmiljøet. Samtidige versioner af en service Serviceplatformen understøtter generelt mere end 1 samtidig version af en udstillet service, efter følgende principper: En ikke-kompatibel version erstatter ikke den tidligere. Her gælder det at o o Ikke-kompatible versioner har forskellige major versionsnummer Det tilstræbes kun at udstille to ikke-kompatible versioner samtidigt En bagud-kompatibel versioner erstatter den tidligere. Her gælder det at o o Kompatible versioner har samme major versionsnummer Det kun er den nyeste version der er tilgængelig, da anvendersystemet ikke bør blive berørt af opgraderingen. Dette giver udslag i følgende regler om samtidige versioner af Services: Services udstilles principielt kun i 2 versioner, hver med forskellige Major numre. På områder, hvor det er særdeles vanskeligt, kostbart eller tidskrævende at tilpasse Anvendersystemer til nye services, kan 3 versioner, hver med forskellige Major numre, udstilles. Dette skal dog så vidt muligt minimeres. Hvis en bagud kompatibel ændring foretages til en udstillet service, erstattes den udstillede udgave med den nye udgave. Dette betyder at for hvert Major nummer er kun den seneste version udstillet (dvs de højste Minor og Micro numre). Når et nyt Major nummer introduceres, skal det ældste normalt elimineres i samme servicevindue, jf. ovenstående, således at der generelt udstilles 2 (eller 3) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 4/9
versioner med forskellige Major numre. Såfremt der efter introduktionen kun er 2 (eller 3) sådanne versioner, er der ikke behov for at eliminere nogen af disse. Vedrørende fejlhåndtering/rollback af services gælder følgende: Ved genintroduktion af en ældre major (ikke-kompatibel) version gælder fortsat reglen om kun 2 (eller 3) forskellige Major numre. Ved genintroduktion af en ældre minor eller build (kompatibel) version gælder reglen om at versionen med det højeste Minor/Micro nummer anvendes. Ved rollback udstilles den fejlramte version således ikke længere. Eksempler på konsekvenser af idriftsættelse af en ny service Ny Major version: Servicen cpr-service, er i drift i to versioner: 1.3.0.10 og 2.0.0.15, Version 3.0.0.30 idriftsættes. Ingen af de tre versioner kan forventes at være kompatible. I forbindelse med idriftsættelsen elimineres version 1.3.0.10. Herefter findes version 2.0.0.15 og 3.0.0.30 i drift. Anvendersystemer der hidtil har benyttet version 1.3.0.10 skal nu anvende version 2.0.0.15 eller version 3.0.0.30. Der er ingen ændring for anvendere af version 2.0.0.15. Ny Minor version: Servicen cpr-service, er i drift i version: 1.3.0.10 og 2.0.0.15, Version 2.1.0.20 idriftsættes. Version 2.1.0.20 er med sikkerhed bagud kompatibel med version 2.0.0.15, og kan anvendes som erstatning for version 2.0.0.15. I forbindelse med idriftsættelsen elimineres version 2.0.0.15. Herefter findes version 1.3.0.10 og 2.1.0.20 i drift. Ny Build version: Servicen cpr-service er i drift i to versioner: 1.3.0.10 og 2.0.0.15 Version 1.3.1.12 idriftsættes Version 1.3.0.10 er med sikkerhed kompatibel med version 1.3.1.12 (og omvendt). I forbindelse med idriftsættelsen elimineres version 1.3.0.10. 1. Eksempler på genintroduktion af udfasede versioner KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 5/9
Fejl i Major version: Servicen "cpr-service, er i drift i to versioner: 2.0.0.15 og 3.0.0.30 Der er fejl i version 3.0.0.30 Repræsentanter for anvendersystemer af v.3.0.0.30 adviseres og alternativer drøftes inden der tages beslutning om at version 1.3.0.10 genidriftsættes. Version 3.0.0.30 elimineres, jf. R4. Herefter findes version 1.3.0.10 og 2.0.0.15 i drift. Fejl i Minor version: Servicen "cpr-service, er i drift i to versioner: 1.3.0.10 og 2.1.0.20, Der er fejl i version 2.1.0.20, og version 2.0.0.15 genidriftsættes. Version 2.1.0.20 elimineres, jf. R5. Herefter findes version 1.3.0.10 og 2.0.0.15 i drift. Fejl i Build version: Servicen "cpr-service, er i drift i to versioner: 1.3.1.12 og 2.0.0.15, Der er fejl i version 1.3.1.12, og version 1.3.0.10 genidriftsættes. Version 1.3.0.10 elimineres, jf. R5. Herefter findes version 1.3.0.10 og 2.0.0.15 i drift. Advisering af nye versioner til leverandører af anvendersystemer Ved introduktion af en ny version, eller når en eksisterende version skal elimineres, skal leverandørerne af anvendersystemerne adviseres. Principperne for advisering om nye versioner af udstillede defineres som for Serviceplatformen, men med følgende frister: Ændringer til udstillede services, der kræves udrullet grundet rettelser af fatale fejl eller sikkerhedsrelaterede fejl eller mangler, foretages af KOMBIT uden foregående advisering. Efter opdatering adviseres generelt via nyheder om Serviceplatformens driftsstatus. Ændringer der udelukkende resulterer i en positiv ændring af versionens Build nummer eller Micro nummer, foretages af KOMBIT uden foregående advisering. Ændringer der resulterer i en positiv ændring af versionens Minor nummer, eller en negativ ændring i versionens Build nummer, foretages af KOMBIT efter en generel advisering af leverandører af anvendersystemerne, med mindst 10 kalenderdages varsel. Ændringer der resulterer i en ændring af versionens Major nummer, eller en negativ ændring af versionens Minor nummer (dvs. rollback), foretages først af KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 6/9
KOMBIT efter en generel advisering af leverandører af anvendersystemerne, med mindst 1 kalendermåneds varsel, og med så lang varsel som muligt ved rollback. Gamle Major versioner af en udstillet service kan elimineres efter mindst 3 kalendermåneders forudgående varsel til leverandører af anvendersystemer, men kun såfremt der er mere end 2 (eller 3) forskellige Major versioner, jf. ovenstående. Advisering skal generelt tage højde for perioder med mindre fokus såsom ferieperioder, hvor adviseringsfrister bør regnes EFTER perioden er afsluttet, dvs medio august for sommerferiens vedkommende, i stedet for ultimo juni. 4. Versioneringsstrategi og kompatibilitet for Serviceplatformen Versioneringsstrategi Serviceplatformen udvikles løbende i nye versioner, og versioneres efter følgende principper: 1. Serviceplatformens versionsnummer har 4 komponenter: Major, Minor, Micro og Build, der er naturlige, positive tal. De skrives med. i mellem, eksempelvis 1.2.3.4. 2. Hvis en ny version er ændret i en grad, der gør at eksisterende anvendersystemer SKAL ændres for at anvende den funktionalitet, de har adgang til for indeværende, skal den nye version have et højere Major nummer. 3. Hvis en ny version er ændret i en grad, der gør at eksisterende anvendersystemer kan anvende eksisterende funktionalitet, men brug af den nye funktionalitet kræver tilpasning af anvendersystemet, skal den nye version have et højere Minor nummer. 4. Hvis en ny version er ændret i en grad, der ikke kræver ændringer af et eksisterende anvendersystem for at anvende ændringen, skal den nye version have et højere Micro nummer. 5. Hver officiel distribution af Serviceplatformen får et nyt Build nummer. 6. Ved skift af Major nummer nulstilles Minor og Micro numre. 7. Ved skift af Minor nummer nulstilles Micro nummeret. Eksempler på ændringer Hvis Serviceplatformens Invocation Context (standard kaldsinformation til alle kald) ændres således at en ny obligatorisk parameter introduceres, vil dette typisk kræve en ny Major version (samt typisk nye Major versioner for samtlige udstillede services). Hvis den nye parameter ikke er obligatorisk, vil det typisk kræve en ny Minor version. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 7/9
Hvis Serviceplatformens sikkerhedskrav ændres (eksempelvis skift af certifikatudbyder eller skift fra certifikater til brugernavn/password) vil dette typisk kræve en ny Major version. En simpel fejlrettelse i Serviceplatformen vil typisk kun kræve en ny Micro version. Kompatibilitet Givet versionering af Serviceplatformen som defineret ovenfor, gælder det at: en Major version N er IKKE kompatibel med andre Major versioner en Minor version N er KUN kompatibel med andre versioner der har samme Major nummer og lavere Minor nummer, og ellers ikke en Micro version N er kompatibel med alle andre versioner der har samme Major og Minor nummer, og ellers ikke Build nummeret har ingen konsekvens for kompatibilitet. Eksempler på kompabitilitet Version 5.4.0.123 er (bagud) kompatibel med version 5.3.4.100 Version 5.3.1.96 og version 5.3.2.98 er gensidigt kompatible. Version 4.8.0.65 er IKKE kompatibel med 5.0.0.70. 8. Versioneringsstrategi og kompatibilitet for services udstillet af Serviceplatformen En udstillet service består af tre dele: 1. Servicens grænseflade, der specificerer hvordan en forespørgsel foretages, som fx krævede parametre og værdier, sikkerhedsparametre, og indholdet i svaret på en forespørgsel. 2. Servicens implementering, der er realiseringen af den ønskede funktionalitet eller adgang til data. 3. Servicens indhold er det, der udstilles af servicen (data og funktionalitet). Der kan være behov for at ændre i både definitionerne af indholdet, implementeringen, såvel som i den tekniske grænseflade. Visse ændringer i en Service er kompatible med tidligere udgaver, hvorimod andre ændringer er inkompatible. Ved en bagud kompatibel ændring af Service forstås en ændring, der KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 8/9
ikke kræver nogen korresponderende ændring hos anvendersystemer. Hvis en ændringer derimod kræver en korresponderende ændring i Anvendersystemet, er den principielt ikke bagud kompatibel, selvom ændringen er minimal. Versionsnumre til Services Services versioneres på samme måde som Serviceplatformen, som beskrevet i afsnit 4. Eksempler på ændringer til SOAP-baserede webservices En ny forespørgselsparameter tilføjes til en metode i en udstillet service. Hvis den nye parameter er obligatorisk, skal den nye service have ny Major version. Hvis den nye parameter ikke er obligatorisk, skal den nye service have ny Minor version. En ny svarparameter tilføjet til en metode i en udstillet service. Den nye service skal have ny Major version. En ny metode tilføjes til en udstillet service. Den nye service skal normalt kun have nyt Minor nummer. En ny type tilføjes til definitionen af en udstillet service. Den nye service skal normalt kun have nyt Micro nummer. Hvis en ny metode, der anvender denne type, ligeledes tilføjes, skal den nye service have nyt Minor nummer. En udstillet services fejlrettes, eller implementeringen ændres, men servicen udstiller fortsat samme data eller funktionalitet. I dette tilfælde skal den nye service normalt kun have nyt Micro nummer. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 9/9