Gérer développement, préproduction et production
Publié le · Mis à jour le
Gérer développement, préproduction et production consiste à définir leur rôle, leurs données et leurs connexions. Testez une version identifiable avec des réglages vérifiés, puis examinez le résultat réel après publication.
Définir les environnements existants
Listez les environnements réellement disponibles. Réservez le développement au travail courant, la préproduction à la revue d’une version candidate et la production à l’usage réel. Notez adresse, responsable, version active et moyen d’identification. Affichez un repère visible dans les espaces de test pour éviter leur confusion avec l’application publique. Si seule une prévisualisation existe, décrivez les essais possibles et leurs limites. Ne la considérez pas automatiquement comme un environnement indépendant avec toutes ses ressources séparées.
Choisissez un parcours de revue, par exemple créer une demande de service, l’afficher puis modifier son état. Précisez point de départ, données d’exemple et personne vérifiant le résultat. Avec Infera Agent, contrôlez les possibilités de prévisualisation, publication et gestion des ressources avant de construire le plan. Ne présumez pas l’existence d’un bouton de transfert ou de duplication. Sans environnement indépendant, concevez un essai limité avec les options disponibles et documentez ce qu’il peut affecter et ce qu’il ne prouve pas.
- Listez les espaces et adresses réels.
- Notez rôle, responsable et version.
- Décrivez les limites des essais.
Vérifier réglages et données
Préparez une liste par environnement : source des données, destinations des services, adresse de retour et accès de l’équipe. Examinez les valeurs utilisées par le projet, pas une ancienne note. Les réglages peuvent varier entre déploiements et être séparés du code par des variables d’environnement selon la conception. Référence : https://www.12factor.net/config . Notez nom, usage et responsable sans copier de valeurs secrètes. Vérifiez les valeurs absentes et leur comportement avant le parcours complet. Une liste remplie ne remplace pas l’examen des réglages réellement actifs.
Préparez des exemples couvrant les états nécessaires : demande nouvelle, en cours et terminée, avec texte long ou information absente si pertinent. Confirmez destination de sauvegarde et compte voyant les données. Des exemples construits avec soin suffisent souvent sans copier des informations clients. Pour un message ou une connexion externe, écrivez la destination attendue puis vérifiez le résultat. Une étiquette de test à l’écran ne prouve pas que toutes les connexions utilisent des destinations de test. Contrôlez donc l’opération elle même et conservez sa référence.
- Examinez les réglages réellement utilisés.
- Vérifiez sauvegarde et destinations.
- Préparez des cas clairement définis.
Tester une version et noter les écarts
Associez la revue à une version ou un changement identifiable. Des environnements peuvent exécuter différentes versions du même projet ; référence : https://12factor.net/codebase . Définissez modification et critères avant l’essai. Pour une demande de service, contrôlez un enregistrement unique, sa visibilité au bon compte et un changement d’état sans modification étrangère. Essayez saisie manquante, retour et réouverture. Conservez résultats, version et environnement afin de ne pas transformer une observation ancienne en preuve concernant une version plus récente. Gardez cas et résultat attendu ensemble.
Comparez les facteurs influençant le comportement entre préproduction et production. Réduire les différences limite les écarts de test ; référence : https://www.12factor.net/dev-prod-parity . Ne déclarez pas les espaces identiques sans contrôle. Données, connexions et utilisateurs peuvent différer ; notez ce qui reste non vérifié et doit être observé pendant la publication. Après changement de version durant la revue, rejouez les cas concernés. Un ancien succès ne valide pas une nouvelle modification parce que son nom ou son apparence reste semblable. Traitez chaque écart important explicitement.
- Reliez résultats, version et environnement.
- Vérifiez parcours et données enregistrées.
- Documentez écarts et limites.
Publier et vérifier la production
Préparez un suivi court : version attendue, réglages revus, essais et responsable. Distinguez préparation, association aux réglages et exécution ; référence : https://www.12factor.net/build-release-run . Utilisez les étapes disponibles sans inventer de commandes ou de boutons. Après transfert, vérifiez adresse, version, parcours essentiel et résultat enregistré. Une page ouverte ne démontre pas une opération réussie. Examinez message utilisateur, état et destinations associées. Choisissez une vérification appropriée qui ne crée pas accidentellement de demande réelle ou d’effet externe indésirable lors du contrôle.
Précisez la réponse à un problème : personne chargée de l’évaluation, preuves disponibles et moyens de limiter l’effet ou de revenir à une version adaptée. Un retour applicatif ne restaure pas nécessairement les données antérieures ; vérifiez la compatibilité avec les données actuelles. Séparez traitement des enregistrements affectés et correction du comportement futur. Notez décisions, résultats et limites du suivi, puis actualisez la liste des environnements. L’équipe doit connaître ce qui fonctionne maintenant et ce qui reste à surveiller, sans dépendre de la mémoire d’une seule personne.
- Vérifiez version et parcours en production.
- Séparez retour applicatif et réparation des données.
- Notez décisions et suivi.
Questions
Une prévisualisation est elle la préproduction ?
Pas nécessairement. Examinez ressources, données, connexions et comportements vérifiables. Documentez ses limites avant d’utiliser le résultat comme preuve.
Que transférer entre environnements ?
La version prévue avec des réglages adaptés, selon les outils du projet. Copier du contenu ne garantit pas le bon transfert des données et connexions.
Un test réussi garantit il la production ?
Non. Documentez différences et vérifiez le parcours après publication. Le résultat concerne une version, un environnement et des cas définis.
Que contrôler avant un retour ?
Disponibilité de la version, compatibilité avec les données actuelles et conséquences des opérations réalisées. Prévoyez un traitement distinct des enregistrements affectés.