Hoppa till innehåll
BigTree108

Tjänster för modernisering av legacy-mjukvara

Modernisering av legacy-mjukvara för system som fortfarande driver verksamheten men bromsar den: övertaganden av kod som andra team har skrivit, uppgraderingar till aktuella versioner och stegvis ersättning av gamla moduler, utan en omskrivning i ett svep. Nio system har kommit till oss från andra team hittills, det äldsta skrevs 2008.

Så moderniserar vi ett legacy-system

  • En skrivskyddad granskning först

    Koden, beroendena, driftsättningen och datan genomlästa från början till slut innan någon ändrar en rad, med en skriftlig lista över risker i ordning efter påverkan på produktionen.

  • Tester runt det som finns

    Karakteriseringstester som låser fast vad systemet gör i dag, egenheter inräknade, så att varje senare ändring kontrolleras mot verkligt beteende i stället för minnet.

  • Uppgraderingar av ramverk och runtime

    .NET Framework till aktuell .NET, Java 8 till en aktuell LTS, PHP 5 till PHP 8, Python 2 till 3 och AngularJS till Angular, ett steg i taget, där varje steg släpps för sig.

  • Ersättning enligt strangler-fig-mönstret

    Nya moduler byggda vid sidan av det gamla systemet bakom ett routinglager och som tar över en funktion i taget tills den gamla koden kan stängas av, utan någon enskild dag då allt ändras.

  • Modernisering av databasen

    Affärslogik flyttad ur lagrade procedurer till testad kod, schemaändringar omvandlade till versionerade migreringar och data på databasversioner som inte längre stöds flyttade med en avstämningsrapport.

  • Säkerhetsskuld som betalas av

    Beroenden som inte längre stöds ersätts, kända sårbarheter åtgärdas, hemligheter flyttas ur konfigurationsfiler till ett valv och beroendeskanning införs i pipelinen så att skulden inte kommer tillbaka.

Anlita ingenjörer för legacy-system

  • Dedikerade ingenjörer för legacy-system

    Ingenjörer för legacy-system som går med i ert team på heltid, arbetar i era verktyg och er process och rapporterar till er teamledare. Ni intervjuar dem; vi står för det ukrainska avtalet, lönen, faktureringen och ledigheten.

  • Projekt inom Modernisering

    En avgränsad insats inom modernisering med omfång, fast plan och en namngiven ledare hos oss som äger resultatet och rapporterar framsteg i era kanaler.

  • Löpande modernisering

    Modernisering som löpande tjänst: samma personer varje månad, en backlog ni prioriterar och timmar ni kan se i vår portal och på fakturan.

Sidan om dedikerade team förklarar hur specialister går med i ert team, och sidan om outsourcing beskriver projektleverans, övertaganden och hur vi debiterar.

Vilka som arbetar med modernisering åt er

  • Teknisk ledare

    Äger granskningen, risklistan och arbetsordningen

  • Ingenjörer inom .NET, Java och PHP

    Uppgraderingar och refaktorering i systemets eget språk

  • Moln- och DevOps-ingenjörer

    Pipelines, infrastruktur som kod och flytten bort från gamla servrar

  • QA-ingenjörer

    Karakteriserings- och regressionstester

Modernisera i steg, inte i en enda omskrivning

En fullständig omskrivning stoppar leveranserna i månader och förlorar oftast beteenden som ingen skrivit ned. Vi moderniserar i stället i steg: vart och ett så litet att det kan släppas, testat mot vad systemet gjorde förut och valt efter den risk eller kostnad det tar bort, så att verksamheten fortsätter köra på systemet medan det förändras.

Ett övertagande börjar med en skrivskyddad granskning och en skriftlig lista över risker före varje åtgärd. Ibland visar listan att en modul hellre bör skrivas om, och då säger vi det, med skälen skriftligt och omskrivningen planerad bakom samma tester.

Andra lösningar vi levererar

Översikt: Lösningar

Frågor om modernisering av legacy-system

Ska vi skriva om eller modernisera?

Oftast modernisera. En omskrivning är rimlig för en modul vars beteende är väl förstått och vars kod blockerar varje ändring; för resten ger stegvisa uppgraderingar och ersättning enligt strangler-fig-mönstret värde tidigare och bevarar den kunskap som är inbyggd i den gamla koden. Granskningen ger er det beslutet per modul, skriftligt.

Våra ursprungliga utvecklare har slutat. Kan ni ändå ta över systemet?

Ja. Vi arbetar utifrån koden, databasen, driftsättningen och de personer som fortfarande använder systemet, och den skriftliga risklistan visar vad vi hittade innan ni bestämmer vad som ska ändras.

Fortsätter det gamla systemet att köra medan det moderniseras?

Ja. Åtgärder och säkerhetsuppdateringar fortsätter på det levande systemet hela tiden, och varje moderniseringssteg släpps för sig, så det finns aldrig en period då verksamheten väntar på den nya versionen.

Hur snabbt kan ingenjörer för legacy-system börja?

När rätt moderniseringsingenjör finns tillgänglig styrs starten bara av er intervju samt NDA och IP-överlåtelse. Annars gör vi en sökning, som vanligtvis ger kandidatprofiler inom två till tre veckor, och ingen börjar förrän ni har sagt ja.

Hur anlitar vi ingenjörer för legacy-system via BigTree108?

Berätta om arbetet, senioriteten och de timmar ni behöver. Vi föreslår en eller två personer med deras profiler, ni intervjuar dem på samma sätt som ni skulle intervjua en egen anställning, och ni skriver under ett avtal med BIG TREE 108 LLC och får en faktura i månaden.

Vem äger arbetet de producerar?

Det gör ni. Varje specialist har ett undertecknat avtal med BigTree108 som överlåter allt arbetsresultat till bolaget, och vårt avtal med er överlåter det vidare. Kod, designer och dokument levereras in i era egna repositories och verktyg, inte på ett ställe där bara vi kan ändra dem.

Har ni ett system som ingen vill röra?

Skicka kodförvaret eller en beskrivning av systemet. Ni får svar inom en arbetsdag: en plan för granskningen och de första stegen efter den.