Begynn moderniseringen av en eldre applikasjon med å skrive ned hvorfor den må endres, og vurder deretter koden og produksjonen sammen. Stabiliser systemet og legg tester rundt oppførselen virksomheten er avhengig av, før du endrer strukturen. Med det sikkerhetsnettet på plass kan du erstatte systemet bit for bit, flytte data på en kontrollert måte og spare en fullstendig omskriving til de sjeldne tilfellene der lite er verdt å beholde.
Sett ord på forretningsgrunnen før du rører koden
Modernisering er dyrt, så start med grunnen. Vanlige grunner er et kjøremiljø eller rammeverk som har passert slutten av levetiden, endringer som tar uker fordi hver lansering ødelegger noe, et system som bare én person forstår, eller en plattform som ikke kan støtte det virksomheten trenger videre. Hver grunn peker mot et annet første steg.
Skriv ned grunnen sammen med et mål du kan sjekke senere, for eksempel hvor ofte du lanserer, hvor mange hendelser som oppstår, eller hvor lang tid en vanlig endring bruker på å nå brukerne. Uten det blir moderniseringen et utviklingsprosjekt uten ende som er vanskelig å forsvare ved neste budsjettgjennomgang.
Vurder koden og produksjonen før du bestemmer noe
En vurdering forteller deg hva du faktisk har. Hold den kort, og la den ende med en skriftlig rapport og et anbefalt første steg. Les koden, men les også produksjonen: logger, hendelser, trege spørringer og måten lanseringer gjøres på. De verste problemene ligger ofte rundt koden heller enn i den.
- Versjoner av kjøremiljø, rammeverk og biblioteker, og hvilke av dem som ikke lenger får sikkerhetsoppdateringer
- Hvilke deler som endres oftest, og hvilke som går i stykker oftest, ut fra versjonshistorikken og hendelsesloggen
- Testdekning på flytene virksomheten er avhengig av
- Hvordan applikasjonen bygges, konfigureres og rulles ut, og hvem som kan gjøre det
- Datamodellen, størrelsen på den, og hvilke andre systemer som leser fra eller skriver til den samme databasen
- Personene som kjenner systemet, og hva bare de vet
Stabiliser produksjonen først, slik at arbeidet har et stødig grunnlag
Hvis systemet svikter hver uke, blir moderniseringen avbrutt hver uke. Rett først det som forårsaker hendelser: legg til overvåking og varsler på kritiske flyter, automatiser bygg og utrulling slik at lanseringer kan gjentas, og flytt hemmeligheter og konfigurasjon ut av koden.
Disse stegene lønner seg med én gang og gjør hvert senere steg tryggere. De viser også tidlig om teamet kan endre systemet uten å ødelegge det, noe som er verdt å vite før du forplikter deg til en større plan.
Bygg et sikkerhetsnett av tester rundt oppførselen du er avhengig av
Eldre kode har som regel få tester, og den dokumenterte oppførselen stemmer sjelden med den faktiske. Før du endrer strukturen, bør du skrive karakteriseringstester: tester som registrerer hva systemet gjør i dag, inkludert de rare grensetilfellene, slik at enhver endring i oppførsel viser seg som en test som feiler.
Start i kantene, med tester som kaller applikasjonen gjennom API-et eller brukergrensesnittet og sjekker resultatene, fordi de overlever interne endringer. For beregninger og rapporter kan du spille av ekte inndata gjennom den gamle og den nye koden og sammenligne resultatene. Legg til mer finmaskede tester i hver del etter hvert som du refaktorerer den. Artikkelen vår om oppgradering av en kritisk Java 8-applikasjon viser det samme sikkerhetsnettet brukt på en oppgradering av kjøremiljøet.
Erstatt systemet bit for bit i stedet for å skrive det om
En fullstendig omskriving ser ryddig ut på papiret, men det gamle systemet fortsetter å kjøre og endre seg mens det nye tar igjen, og hver udokumentert oppførsel må oppdages på nytt underveis. Det er derfor omskrivinger så ofte tar lengre tid enn planlagt, mens virksomheten venter.
Det vanlige alternativet er strangler fig-mønsteret. Sett et rutinglag, for eksempel en reverse proxy eller en API-gateway, foran den eldre applikasjonen. Bygg én funksjon om gangen i den nye koden, og send trafikken for den funksjonen dit når den har vist at den fungerer. Det gamle systemet krymper til det kan slås av, og virksomheten får verdi for hvert steg.
En omskriving kan likevel være riktig: når kodebasen er liten og oppførselen godt forstått, eller når plattformen den kjører på, ikke kan holdes i live lenge nok til en gradvis erstatning. Bestem deg ut fra skriftlige kriterier, ikke frustrasjon.
Behandle dataene som en egen migrering
Kode kan erstattes i skiver; data er vanskeligere å dele opp. Så lenge den gamle og den nye koden deler én database, må hver endring i skjemaet koordineres. Bestem tidlig hvilket system som er sannhetskilden for hver type data, og unngå at to systemer skriver til den samme posten uten en regel for hvilken skriving som vinner.
Når en funksjon flyttes, må dataene flyttes eller synkroniseres på en kontrollert måte: migreringsskript testet mot en kopi av produksjonen, eller løpende synkronisering mens begge systemene kjører. Planlegg hvordan du skal avstemme de to, for eksempel med daglige tellinger og kontrollsummer, og behold muligheten til å bytte tilbake til tallene stemmer.
Ordne arbeidet etter risiko og verdi, og vis fremdrift tidlig
Legg opp arbeidet slik at hvert steg enten reduserer risiko eller leverer noe virksomheten kan se. En vanlig rekkefølge er å stabilisere og automatisere, legge til tester, oppgradere kjøremiljøet og deretter skille ut funksjonene som endres oftest. Deler som er stabile og sjelden røres, kan vente, noen ganger på ubestemt tid.
Hold planen kort, og gå gjennom den etter hvert steg, fordi det du lærer, vil endre rekkefølgen. Utviklerne våre har jobbet slik på kritiske systemer. Gjennom Sopra Steria ledet de en migrering fra Java 8 til 16 av en kritisk applikasjon for dagshandel med gass, og som en del av programteamet i skyprogrammet til Crédit Agricole vurderte vi hver applikasjon vi migrerte, for å avgjøre om den skulle oppgraderes eller bygges på nytt. Hvis du vil ha en vurdering av ditt eget system, eller et team som gjennomfører planen, gjør SDK Enterprises begge deler under én kontrakt.
Det viktigste
- Skriv ned forretningsgrunnen for å modernisere, med et mål du kan sjekke senere.
- Vurder kode og produksjon sammen før du velger mellom oppgradering, gradvis erstatning og omskriving.
- Stabiliser produksjonen og legg karakteriseringstester rundt kritisk oppførsel før du endrer strukturen.
- Erstatt systemet bit for bit bak et rutinglag, med mindre en omskriving klart er mindre og tryggere.
- Planlegg eierskap til data, synkronisering og avstemming som en egen migrering.
Spørsmål og svar
Bør vi skrive den eldre applikasjonen vår om fra bunnen av?
Som regel ikke. En omskriving konkurrerer med et system som fortsetter å endre seg, og må gjenoppdage oppførsel som ingen har dokumentert. Erstatt den gradvis, med mindre kodebasen er liten og godt forstått, eller knyttet til en plattform som ikke kan holdes i drift.
Hvor lang tid tar det å modernisere en eldre applikasjon?
Det avhenger av hvor stort systemet er, testdekningen, hvor sammenfiltrede dataene er, og hvor mye som må endres. En kort vurdering gir deg en realistisk plan og et første steg som er lite nok til å fullføres og måles, heller enn én dato for hele arbeidet.
Kan vi fortsette å lansere nye funksjoner mens vi moderniserer?
Ja, og det bør dere. Gradvis erstatning lar teamet levere funksjoner i den nye koden mens det gamle systemet fortsetter å kjøre. Avtal hvor mye av teamets tid som går til modernisering, slik at arbeidet med nye funksjoner ikke i det stille spiser den opp.