Gå til indhold
BigTree108

Modernisering af ældre software

Modernisering af ældre software til systemer, der stadig driver forretningen, men bremser den: overtagelse af kode, andre teams har skrevet, opgraderinger til nuværende udgivelser og trinvis udskiftning af gamle moduler, uden en big bang-omskrivning. Ni systemer er hidtil kommet til os fra andre teams, det ældste skrevet i 2008.

Sådan moderniserer vi et ældre system

  • Først en gennemgang uden skriveadgang

    Koden, afhængighederne, udrulningen og dataene læst fra ende til anden, før nogen ændrer en linje, med en skriftlig liste over risici i rækkefølge efter betydning for driften.

  • Tests omkring det, der findes

    Karakteriseringstests, der fastholder, hvad systemet gør i dag, sære forhold inklusive, så hver senere ændring kontrolleres mod reel adfærd frem for hukommelse.

  • Opgradering af framework og runtime

    .NET Framework til nuværende .NET, Java 8 til en nuværende LTS, PHP 5 til PHP 8, Python 2 til 3 og AngularJS til Angular, ét trin ad gangen, hvor hvert trin udgives for sig.

  • Udskiftning efter strangler-fig-mønsteret

    Nye moduler bygget ved siden af det gamle system bag et routinglag, der overtager én funktion ad gangen, indtil den gamle kode kan slukkes, uden at der er en enkelt dag, hvor alt ændrer sig.

  • Modernisering af databasen

    Forretningslogik flyttet ud af stored procedures til testet kode, skemaændringer omdannet til versionerede migreringer og data på ikke-understøttede databaseversioner flyttet med en afstemningsrapport.

  • Sikkerhedsgæld betalt ned

    Ikke-understøttede afhængigheder erstattet, kendte sårbarheder rettet, hemmeligheder flyttet fra konfigurationsfiler til en vault og scanning af afhængigheder i pipelinen, så gælden ikke vender tilbage.

Ansæt udviklere til ældre systemer

  • Dedikerede udviklere til ældre systemer

    Udviklere til ældre systemer, der indgår i jeres team på fuld tid, arbejder i jeres værktøjer og processer og rapporterer til jeres leder. I interviewer dem; vi står for den ukrainske kontrakt, lønudbetalingen, faktureringen og ferie og orlov.

  • Projekter inden for Modernisering

    En afgrænset opgave inden for modernisering med et fast omfang, en fast plan og en navngiven leder hos os, der ejer resultatet og rapporterer fremdriften i jeres kanaler.

  • Løbende modernisering

    Modernisering som løbende ydelse: de samme folk hver måned, en backlog, I selv prioriterer, og timer, I kan se i vores portal og på fakturaen.

Siden om dedikerede teams forklarer, hvordan specialister indgår i jeres team, og siden om outsourcing beskriver projektleverance, overtagelser og hvordan vi tager betaling.

Hvem arbejder med jeres modernisering

  • Teknisk leder

    Har ansvaret for gennemgangen, risikolisten og rækkefølgen af arbejdet

  • .NET-, Java- og PHP-udviklere

    Opgraderinger og refaktorering i systemets eget sprog

  • Cloud- og DevOps-ingeniører

    Pipelines, infrastructure as code og flytningen væk fra gamle servere

  • QA-ingeniører

    Karakteriserings- og regressionstests

Moderniser i trin, ikke i én omskrivning

En fuld omskrivning standser leverancerne i måneder og mister som regel adfærd, ingen har skrevet ned. Vi moderniserer i stedet i trin: hvert så lille, at det kan udgives, testet mod det, systemet gjorde før, og valgt ud fra den risiko eller de omkostninger, det fjerner, så virksomheden kan blive ved med at køre på systemet, mens det ændres.

En overtagelse starter med en gennemgang uden skriveadgang og en skriftlig liste over risici før enhver rettelse. Nogle gange viser listen, at et modul bør skrives om, og så siger vi det, med begrundelserne skriftligt og omskrivningen planlagt bag de samme tests.

Andre løsninger, vi leverer

Løsninger: oversigt

Spørgsmål om modernisering af ældre systemer

Skal vi skrive om eller modernisere?

Som regel modernisere. En omskrivning giver mening for et modul, hvis adfærd er veldefineret, og hvis kode blokerer enhver ændring; for resten leverer trinvise opgraderinger og udskiftning efter strangler-fig-mønsteret værdi hurtigere og bevarer den viden, der er bygget ind i den gamle kode. Gennemgangen giver jer den beslutning pr. modul, skriftligt.

Vores oprindelige udviklere er gået. Kan I stadig overtage systemet?

Ja. Vi arbejder ud fra koden, databasen, udrulningen og de personer, der stadig bruger systemet, og den skriftlige risikoliste fortæller jer, hvad vi fandt, før I beslutter, hvad der skal ændres.

Kører det gamle system videre, mens det moderniseres?

Ja. Rettelser og sikkerhedsopdateringer fortsætter på det kørende system hele vejen, og hvert moderniseringstrin udgives for sig, så der aldrig er en periode, hvor virksomheden venter på den nye version.

Hvor hurtigt kan udviklere til ældre systemer starte?

Når den rette moderniseringsudvikler er tilgængelig, afhænger starten kun af jeres samtale samt NDA og overdragelse af IP-rettigheder. Ellers gennemfører vi en søgning, som typisk giver kandidatprofiler inden for to til tre uger, og ingen starter, før I har sagt ja.

Hvordan ansætter vi udviklere til ældre systemer gennem BigTree108?

Fortæl os om opgaverne, erfaringsniveauet og det timetal, I har brug for. Vi foreslår en eller to personer med deres profiler, I interviewer dem på samme måde, som I ville interviewe jeres egen medarbejder, og I underskriver én aftale med BIG TREE 108 LLC og modtager én faktura om måneden.

Hvem ejer det arbejde, de producerer?

Det gør I. Hver specialist har en underskrevet kontrakt med BigTree108, som overdrager alt arbejdsresultat til virksomheden, og vores aftale med jer overdrager det videre til jer. Kode, designs og dokumenter leveres ind i jeres egne repositories og værktøjer og opbevares ikke et sted, hvor kun vi kan ændre dem.

Kører I et system, ingen vil røre?

Send repositoriet eller en beskrivelse af systemet. I får svar inden for én arbejdsdag: en plan for gennemgangen og de første trin efter den.

Skriv til hello@bigtree108.com Sådan svarer vi