Bestaande software aan een nieuw team overdragen
Controleer de overdracht van een herkenbare bronrevisie tot een kleine, terug te draaien wijziging in de testomgeving.
Laat het nieuwe team de route zelf volgen
Een overdracht wordt concreet als het nieuwe team de toepassing met eigen bevoegde accounts kan opzetten en een afgesproken wijziging kan controleren. Een bronarchief en een demonstratie door het vorige team leveren daarvoor nog niet alle bewijzen.
Koppel eerst de draaiende versie aan een herkenbare bronrevisie. Leg benodigde bestanden, afhankelijkheden, gereedschapsversies en de route naar een uitvoerbaar resultaat vast. SLSA onderscheidt bronnen, andere invoer, builds en verspreide artefacten. Zo kan het nieuwe team herleiden uit welke invoer de overgedragen versie is ontstaan.
Voorbeeld: een tekstwijziging van opbouw tot terugkeer
Dit scenario is fictief. Een serviceformulier wordt op v2.3.0 overgedragen. Het nieuwe team moet de hulptekst “Leveringsnotitie” verduidelijken tot “Toegang en levering”. Gegevensvelden en databaseschema blijven hier ongewijzigd. De tabel beschrijft verwachte bewijzen, geen uitgevoerde test.
Stap | Afgesproken taak | Verwacht bewijs |
|---|---|---|
Bronnen bereiken | Met eigen bevoegd account de vastgelegde bronrevisie en extra bestanden ophalen. | De overgedragen revisie is herkenbaar; vereiste private pakketten en extra repository-inhoud zijn ook bereikbaar. |
Omgeving opzetten | Instructies voor runtime, pakketinstallatie en testconfiguratie volgen. | De testtoepassing start zonder productietoegang of privébestanden van de vorige ontwikkelaar. |
Kleine wijziging controleren | De hulptekst veranderen en de bestaande opslagstroom met synthetische gegevens doorlopen. | De nieuwe tekst verschijnt; de afgesproken opslagstroom werkt nog. |
Wijziging terugdraaien | De tekstwijziging in test terugdraaien en de vastgelegde startroute gebruiken. | De oorspronkelijke tekst en eerder gecontroleerde formulierstroom zijn weer beschikbaar. |
De laatste rij toont alleen de rollback van deze wijziging. Databaseherstel of een productieovergang vraagt eigen passende controles.
Voeg beheer en open punten toe
Documenteer configuratienamen, veilige routes voor geheimen, private pakketbronnen en bestaande buildconfiguratie, inclusief een passend lockbestand voor afhankelijkheden. Echte geheimen horen niet in het bronarchief. Controleer ook apart opgeslagen grote bestanden en opgenomen repositories als het project die gebruikt.
Maak toegang en verantwoordelijkheden voor uitrol, bewaking, back-ups en storingen duidelijk. Bij een GitHub-repositoryoverdracht blijven onder meer webhooks, secrets en deploy keys gekoppeld. Beoordeel uitdrukkelijk welke koppelingen en toegang moeten blijven. Overdracht alleen ruimt ze niet op.
Leg bij mislukking de ontbrekende voorwaarde, verantwoordelijke rol en het volgende bewijs vast. Scheid open punten van aangetoonde resultaten. Spreek af wanneer het nieuwe team welke taken overneemt en wie tot dan bereikbaar blijft.
Bronnen
Geschreven door
- Katharina WeberRedacteur software en technologieKatharina Weber verzorgt bij ASES de artikelen over softwareontwikkeling. Ze schrijft over de vragen waar bedrijven mee te maken krijgen bij het kiezen van software, het ontwikkelen van nieuwe toepassingen en het moderniseren van bestaande systemen.
Verder lezen
Alle artikelen
Softwareontwikkeling met ASES
Maatwerksoftware, web- en mobiele apps