Overlever eksisterende programvare til et nytt team
Kontroller overleveringen fra en entydig kilderevisjon til en liten endring som kan gjøres om i testmiljøet.
La det nye teamet følge veien selv
Overleveringen blir konkret når det nye teamet kan sette opp applikasjonen med egne autoriserte kontoer og kontrollere en avtalt endring. Et kildearkiv og en demonstrasjon fra det forrige teamet gir ikke alle bevis.
Knytt først den kjørende versjonen til en entydig kilderevisjon. Registrer nødvendige filer, avhengigheter, verktøyversjoner og veien til et kjørbart resultat. SLSA skiller kilder, andre inndata, bygg og distribuerte artefakter. Da kan det nye teamet spore hvilke inndata som skapte den overleverte versjonen.
Eksempel: en tekstendring fra oppsett til tilbakeføring
Scenariet er oppdiktet. Et serviceskjema overleveres ved v2.3.0. Det nye teamet skal presisere hjelpeteksten «Leveringsnotat» til «Adkomst og levering». Datafelt og databaseskjema endres ikke her. Tabellen beskriver forventede bevis, ikke en gjennomført test.
Trinn | Avtalt oppgave | Forventet bevis |
|---|---|---|
Nå kildene | Hente dokumentert kilderevisjon og tilleggsfiler med egen autorisert konto. | Den overleverte revisjonen er entydig; nødvendige private pakker og ekstra repositoryinnhold er også tilgjengelige. |
Sette opp miljø | Følge veiledning for runtime, pakkeinstallasjon og testkonfigurasjon. | Testapplikasjonen starter uten produksjonstilgang eller forrige utviklers private filer. |
Kontrollere liten endring | Endre hjelpeteksten og gå gjennom eksisterende lagringsflyt med syntetiske data. | Den nye teksten vises; avtalt lagringsflyt virker fortsatt. |
Tilbakeføre endring | Tilbakeføre tekstendringen i test og bruke dokumentert oppstartsvei. | Opprinnelig tekst og tidligere kontrollert skjemaflyt finnes igjen. |
Siste rad viser bare tilbakeveien for denne endringen. Databasegjenoppretting eller produksjonsovergang krever egne passende kontroller.
Legg til drift og åpne punkter
Dokumenter konfigurasjonsnavn, sikre veier til hemmeligheter, private pakkekilder og eksisterende byggkonfigurasjon med passende låsefil for avhengigheter. Ekte hemmeligheter hører ikke hjemme i kildearkivet. Kontroller også separat lagrede store filer og innebygde repositoryer hvis prosjektet bruker dem.
Avklar tilgang og ansvar for utrulling, overvåking, sikkerhetskopier og feil. Ved overføring av et GitHub-repository forblir blant annet webhooks, secrets og deploy keys tilknyttet. Vurder eksplisitt hvilke koblinger og tilganger som skal bestå. Overføringen rydder ikke opp alene.
Registrer manglende forutsetning, ansvarlig rolle og neste bevis hvis et trinn feiler. Skill åpne punkter fra viste resultater. Avtal når teamet overtar hvilke oppgaver, og hvem som er tilgjengelig frem til da.
Kilder
Les videre
Alle artikler
Programvareutvikling med ASES
Skreddersydd programvare, web- og mobilapper