Transmettre un logiciel existant à une nouvelle équipe
Vérifiez la transmission depuis une révision source identifiée jusqu’à une petite modification réversible dans l’environnement de test.
Laissez la nouvelle équipe suivre le parcours elle-même
La transmission devient concrète quand la nouvelle équipe peut installer l’application avec ses propres comptes habilités et vérifier une modification convenue. Une archive source et une démonstration par l’ancienne équipe n’apportent pas encore toutes les preuves.
Reliez d’abord la version en service à une révision source identifiée. Consignez fichiers requis, dépendances, versions des outils et chemin vers un résultat exécutable. SLSA distingue sources, autres entrées, construction et artefacts distribués. L’équipe peut ainsi retracer les entrées qui ont produit la version transmise.
Exemple : une modification de texte, de l’installation au retour
Ce scénario est fictif. Un formulaire d’intervention est transmis en version v2.3.0. La nouvelle équipe doit préciser l’aide « Note de livraison » en « Accès et livraison ». Champs de données et schéma de base restent inchangés dans cet exemple. Le tableau présente les preuves attendues, pas un test réalisé.
Étape | Tâche convenue | Preuve attendue |
|---|---|---|
Accéder aux sources | Récupérer la révision documentée et les fichiers supplémentaires avec son propre compte habilité. | La révision transmise est identifiée ; paquets privés requis et contenus supplémentaires du dépôt sont aussi accessibles. |
Installer l’environnement | Suivre les instructions de moteur d’exécution, installation des paquets et configuration de test. | L’application de test démarre sans accès à la production ni fichiers privés de l’ancien développeur. |
Vérifier une petite modification | Modifier l’aide et parcourir l’enregistrement existant avec des données synthétiques. | Le nouveau texte apparaît ; l’enregistrement convenu fonctionne toujours. |
Annuler la modification | Annuler la modification du texte en test et suivre le démarrage documenté. | Le texte d’origine et le parcours du formulaire déjà vérifié sont à nouveau disponibles. |
La dernière ligne ne démontre que le retour pour cette modification. Restauration de base ou transition en production nécessitent leurs propres contrôles adaptés.
Ajoutez exploitation et points ouverts
Documentez noms de configuration, voies sûres d’obtention des secrets, sources de paquets privés et configuration de construction, dont un fichier de verrouillage des dépendances adapté. Les vrais secrets ne vont pas dans l’archive source. Vérifiez aussi gros fichiers stockés séparément et dépôts intégrés si le projet en utilise.
Précisez accès et responsabilités pour déploiement, surveillance, sauvegardes et incidents. Un transfert de dépôt GitHub conserve notamment les liens aux webhooks, secrets et clés de déploiement. Examinez expressément quels liens et accès doivent subsister. Le transfert ne les nettoie pas à lui seul.
Si une étape échoue, consignez prérequis manquant, rôle responsable et prochaine preuve requise. Séparez points ouverts et résultats démontrés. Convenez du moment où la nouvelle équipe reprend chaque tâche et du contact disponible jusque-là.
Sources
Écrit par
- Katharina WeberRédactrice logiciels et technologieKatharina Weber s’occupe chez ASES des articles consacrés au développement logiciel. Elle traite des questions que se posent les entreprises lorsqu’elles choisissent un logiciel, développent de nouvelles applications ou modernisent leurs systèmes existants.
À lire aussi
Tous les articles
Développement logiciel avec ASES
Logiciels sur mesure, applications web et mobiles