Programvareoverlevering: hva et nytt team må klare selv

En fullstendig programvareoverlevering bør vurderes etter om et annet team kan sette opp applikasjonen, gjøre en målrettet endring og rulle den ut i et testmiljø. Kildekoden trengs. Det selvstendige forsøket viser om også resten av kunnskapen er overført.

For oppdragsgiveren er det praktiske spørsmålet hvor mye som fortsatt avhenger av en bestemt person eller datamaskin. En tilgjengelig nedlasting svarer ikke på det.

Et rent miljø viser hullene

I et fiktivt eksempel får det nye teamet den godkjente versjonen R-1 av en bestillingsportal. På den tidligere bærbare starter alt. På et rent testsystem mangler likevel nøyaktig kjøremiljøversjon, oppsett av tom database og betydningen av to miljøvariabler. Koden er kommet frem; deler av oppsettet er uklare.

Et langt generelt dokument kan la det samme hullet stå åpent. En nyttig veiledning lar teamet følge trinnene som faktisk trengs. Twelve-Factor-prinsippene skiller variabel konfigurasjon fra kode og anbefaler lignende utviklings- og produksjonsmiljøer. De gir retning, ikke en full overleveringsrapport for enhver teknologi.

En liten endring som bevis

I forsøket installeres R-1 med fastsatte avhengigheter. Teamet oppretter en tom testdatabase, bruker kunstige påloggingsopplysninger og fullfører testordre T-31. Produksjonsnøkler hører ikke hjemme i kodearkivet eller veiledningen.

Deretter endres feltnavnet «Referanse» til «Kundereferanse», applikasjonen bygges på nytt og rulles ut i testmiljøet. Til slutt gjenopprettes forrige versjon. Det lille inngrepet prøver om oppsett, endring, utrulling og tilbakeføring er forstått samlet. Det beviser ikke at alle fremtidige funksjoner beherskes.

Må det tidligere teamet levere manglende trinn, skal de inn i overleveringen og prøves igjen. En muntlig forklaring kan løse øyeblikket; hullet er først varig lukket når kunnskapen er tilgjengelig ved neste forsøk.

Når et mindre omfang er nok

Ved en begrenset utvidelse av en plattform som allerede driftes sammen, kan overlevering av endret kode være et nyttig deltrinn. Et helt nytt driftsmiljø kan være uforholdsmessig. Da må det være tydelig hvilken plattformkunnskap og tilgang som allerede finnes, og hvem som fortsatt har ansvaret.

Testtjenester er også rimelige når ekte koblinger ikke skal brukes i forsøket. Oppgi hvilken del som dermed ikke er prøvd. En simulert betaling dokumenterer ikke en fungerende produksjonskobling.

Ved et fullstendig teambytte er det selvstendige forsøket det sterkere målet. Det gjør gjenstående arbeid synlig før den tidligere kontakten ikke lenger er tilgjengelig. Godkjenningen bør oppgi versjon, fullført arbeidsflyt og åpne avhengigheter.

Kilder

• The Twelve-Factor App: Config

• The Twelve-Factor App: Dev/prod parity