Livssyklushåndtering av Regional DIPS
Livssyklushåndtering av Regional DIPS
Livssyklushåndtering
Årshjul
Årshjul, flytskjema for oppgradering og informasjon rundt ikke-produksjonsmiljøer o.l. ligger i denne Teamskanalen (invitasjonskode; 4wqp2op).
Versjonsoppgraderinger
Det planlegges med to årlige versjonsoppgraderinger av den regionale DIPS tjenesten. Den ene av disse vil være oppgradering til ny Arena hovedversjon (eksempel: Arena 23.x) og vil sannsynligvis være 3. lørdag i oktober. Den andre vil imidlertid være oppgradering til en serviceversjon (eksempel: Arena 23.2.x) som utføres sannsynligvis 2. lørdag i mars forutsatt at dette ikke kolliderer med påsken. Dette vil tre i kraft når moderniseringsløpet er ferdig.
Feilrettinger
Ca en måned etter hver halvårlig produksjonssetting (i prosjektperioden skjer dette også etter konsolideringene) planlegges det med en feilrettingsrelease.
Beslutninger på hvilke feilrettinger som tas inn i disse feilrettingsreleasene tas i Endringsråd DIPS produksjon. I Endringsråd opererer man med følgende kategorier for ønsket feilretting/endring:
Kritisk feilretting – retting av 1A hendelser vil kun informeres om i Endringsråd
Myndighetskrav/regulatorisk endring
Feilretting
Høy nåverdi
Unntak: I prosjektperioden vil beslutning om hvilke feilrettinger som skal tas inn i feilrettingsreleasene tas i IDA-møtene (InnføringDIPSArena). Dette er møter med DIPS AS hvor DIPS Leveranseteam og Regional EPJ modernisering er representert. Beslutningene vil i prosjektperioden kun orienteres om i Endringsråd DIPS produksjon.
Versjonsoppgraderinger, feilrettingsreleaser og tjenesteendringer (nye behov) vil implementeres i regi av DIPS leveranseteam (DLTA)
Kubernetes
Planen er å ta inn kubernetesoppdateringer månedlig. Er det en feilrettingsrelease planlagt samme måned må disse samkjøres.
Oppdrag fra Regional forbedring og Marked
Oppdrag fra Regional forbedring kommer fra Regional DIPS systemansvarlig og er besluttet gjennomført av HSØ
Oppdrag fra Marked kommer fra DIPS Tjenesteutvikler. Kan være behov for forprosjekt, kartlegging, bistand til estimering og tilbudsarbeid og forslag til leveranseplan etc. Kan også være et oppdrag hvor tilbud er akseptert og leveransen skal gjennomføres.
Endringsråd EPJ skal beslutte og/eller informeres om oppdrag fra både Marked og Regional forbedring skal gjennomføres (Metodebok)
Andre tjenesters behov for feilrettinger i DIPS
Følger samme regime som er beskrevet her, og viser til Beskrivelse av endringshåndtering
Skal fortrinnsvis leveres med de fastsatte leveransene
Rekkefølge ved SLA-hovedoppgradering
DIPS Reg Teknisk sandkasse
DIPS Reg Funksjonell sandkasse
DIPS Reg Utvikling
DIPS Reg Test
DIPS Reg Produksjon
DIPS Reg Dataguard
DIPS Reg Katastrofe
DIPS Reg Referanse
DIPS Reg Kurs og øving
DIPS Reg Syntetisk
Se Miljøoversikten over regionale DIPSmiljøer for informasjon om regionale miljø
Patching av DIPS-tjenesten
For å se oversikten over hvilke komponenter som patches, og hvem som er ansvarlig/utførende, se oversikten: Driftsteam Dips - Patching (fisp.no)
Kategori og type endring
|
Kategori |
Kriterier |
Type endring |
Krever |
|
SMALL – kan gjøres løpende Liten til ingen risiko Krever ikke behandling i Endringsråd |
Liten endring, kan kjøres i full drift og kreve lite ressurser fra SP/HF |
Kodeverksoppgradering |
Koordinering Dupkjøring (KFA/App.drift) Informasjon Test |
|
Rapporter – Arena (OBS: Rapporter som krever les-modus hører ikke hjemme i denne kategorien) |
Databasepakker (App.drift/Database) Ressurspakker (KFA) |
||
|
Rapporter – Classic |
Dupkjøring (KFA el. App.drift) |
||
|
Oppdatering av Prokomskjema i Arena (OBS: Nye prokomskjema må behandles i Endringsråd, med innstilling fra faggruppe. Dette pga økonomi) |
Ressurspakker (KFA) Tilganger (KFA) |
||
|
Integrasjonsendring (Med lav risiko) |
Integrasjonstjenester |
||
|
NPR-versjonsoppgradering |
Oppgradering av k8sjobb (App.drift) Informasjon (KFA) Test (KFA) |
||
|
MEDIUM – må vurderes mellom de halvårlige releasene Lav risiko Krever behandling i Endringsråd |
Krever mer koordinering og ressurser Endringen kan i utgangspunktet testes i et miljø uten integrasjoner (eks: DIPS Reg Referanse) |
Klientoppgradering |
Koordinering TAU oppdaterer pakkedokument Applikasjonstilrettelegging oversender kildefiler til appdrift, samt pakker og distribuerer nye klienter Appdrift oppdaterer adminservere med kildefilen for ny klient KFA gjennomfører standard smoketest og test av selve feilrettelsen, dette gjøres på adminserver og via RCP HF gjennomfører AT (Akseptansetest) |
|
Databaseendring |
Koordinering Dupkjøring (App.drift) KFA gjennomføre ST HF gjennomføre AT |
||
|
Integrasjonsendring |
Koordinering Integrasjonstjenester Brøytetest gjennomføres av integrasjonsutvikler før SIT (Systemintegrasjonstest) SIT gjennomføres av relevant fagsystemansvarlig fra HF og SP |
||
|
LARGE – må tas i en av de halvårlige releasene |
Krever mye koordinering og mye ressurser fra både SP og/eller HF Endringen må testes i et testmiljø med integrasjoner |
Klient + databaseoppgradering |
Koordinering Se beskrivelse under Medium |
|
Arenarapporter som krever lesemodus |
Koordinering Appdrift installerer KFA gjennomfører ST HF gjennomfører AT |
(eksempler, ikke uttømmende liste. Må gjøres vurdering på hvert enkelt tilfelle og følger av rutine til innmelding av sak til Endringsråd EPJ, Regional forbedring eller Marked)
- Gå til avsnitt
- Livssyklushåndtering
- Kategori og type endring
