Préparer une mise en production

Le module Mises en production de Portail ZAPP regroupe des changements approuvés dans une mise en production, vérifie qu'elle est prête à sortir, puis suit son déploiement instance par instance : chaque environnement (production, recette, instance d'un client…) suit son propre calendrier. Les responsables des mises en production et les administrateurs pilotent ; les agents du Service Desk consultent.

Les instances cibles

Mises en production → Instances cibles déclare les environnements sur lesquels vous déployez. Ajouter une instance : Nom (unique), Nature (par exemple Production, Recette), Description et Équipe alertée (le groupe prévenu à chaque étape du déploiement). Monter et Descendre règlent l'ordre d'affichage. Une instance n'est jamais supprimée : Inactive, elle n'est plus proposée pour une nouvelle mise en production mais reste dans l'historique.

Le modèle de checklist de sortie

Mises en production → Modèle de checklist de sortie contient les points copiés dans chaque nouvelle mise en production. Quatre points sont fournis, un par Catégorie (Tests, Communication, Documentation, Approbations), affichés dans la langue de chacun. Vous pouvez ajouter, réordonner ou désactiver des points ; saisir un Libellé remplace la traduction (laissez-le vide pour la garder). Les mises en production existantes gardent leur propre copie.

Créer une mise en production

Depuis Mises en production → Liste des mises en production, cliquez sur Nouvelle mise en production :

• Titre et Type (Majeure, Mineure, Urgence) ;
• Responsable des mises en production (un membre de ce groupe, ou — À désigner —) ;
• Début de fenêtre et Fin de fenêtre du déploiement ;
• Notes de version ;
• Instances cibles : cochez celles où elle sera déployée ; le déploiement sera suivi pour chacune.

Elle reçoit un numéro de la forme REL-2026.01, dont la séquence repart chaque année.

Le cycle de vie

Planification → Construction → Déploiement → Support post-déploiement → Clôturée. On peut Revenir en planification depuis la construction, et Annuler la mise en production tant qu'elle n'est pas clôturée (ses changements sont alors libérés pour une autre).

Conditions de sortie :

• Passer en construction exige au moins un changement regroupé (quand le module Changements est installé) ;
• Lancer le déploiement et Clôturer exigent une Checklist de sortie complète ; une checklist vide ne compte jamais comme complète ;
• Clôturer exige aussi que chaque instance soit déployée, ou reportée avec un motif.

Un bandeau sur la fiche indique ce qui manque, avec un lien (Aller à la checklist, Aller aux changements).

Les changements regroupés

Dans la carte Changements regroupés, Ajouter un changement approuvé : recherche par numéro ou titre parmi les changements approuvés ou planifiés. Un changement n'appartient qu'à une mise en production, et sa fiche affiche la mise en production qui le contient. Le contenu se construit en planification et en construction, puis il est figé à partir du déploiement. Si la fenêtre de la mise en production tombe dans une période de gel qui la concerne, la fiche l'affiche en avertissement.

La checklist de sortie

Chaque point se coche ou se décoche (Cocher, Décocher), avec l'auteur et la date. Un Point à ajouter pour cette mise en production peut compléter la liste. Ajouter ou décocher un point après coup rouvre la condition de sortie.

Le déploiement par instance

La carte Déploiement par instance suit chaque instance : En attente → En cours → Déployé, ou Échoué, ou Reporté. Les actions sont Démarrer le déploiement, Marquer déployée, Déclarer un échec, Reporter et Remettre en attente, avec un Commentaire (facultatif).

• Un échec ou un report sur une instance ne bloque aucune autre ;
• Reporter exige un Motif du report ;
• avant le déploiement (planification, construction), seul le report est possible ;
• chaque instance a sa Date prévue propre et son Historique de l'instance ; une instance dont la date prévue est passée sans être déployée ni reportée est signalée En retard ;
• une instance s'ajoute (Ajouter l'instance) tant que la mise en production n'est pas close, et se retire (Retirer l'instance) en planification ou en construction si elle n'a jamais été déclarée.

À chaque passage en cours, déployée, en échec ou reportée, le responsable des mises en production et l'équipe alertée de l'instance sont prévenus.

Escalader en incident majeur : sur une instance en échec, quand le module Incidents majeurs est installé et que vous en avez le droit, un clic crée l'incident et l'incident majeur, préremplis avec la mise en production, l'instance et la cause saisie. Un même échec renvoie toujours au même incident majeur ; un nouvel échec en crée un nouveau.

Health check : en déploiement et en support post-déploiement, sur une instance en cours, déployée ou en échec, vous pouvez lancer un Script de vérification approuvé du module d'exécution de scripts. Le résultat (Réussi ou Échoué) est conservé sur la ligne (Dernier health check). Le bouton n'apparaît que si de tels scripts existent et que vous pouvez les exécuter.

La Matrice mise en production × instance donne la vue d'ensemble : une cellule colorée par mise en production et par instance, les retards et les incidents majeurs ouverts.

Le support post-déploiement (hypercare)

Quand une instance est Déployée, elle entre en hypercare pour 14 jours par défaut (l'administrateur règle cette durée) ; Modifier la fin d'hypercare l'ajuste instance par instance. La carte Support post-déploiement suit les tickets liés à la sortie :

• Tickets proposés : les tickets ouverts pendant l'hypercare sur les CI des changements inclus, avec un bouton Rattacher ;
• Autre ticket : recherchez un ticket par numéro ou texte, décrivez le Constat, puis Rattacher ;
• suivez chaque ticket (À analyser, Traité, Sans rapport), ou Détacher.

Le rattachement apparaît aussi sur le ticket. Depuis la fiche d'un ticket, l'action Rattacher à la mise en production est proposée aux responsables des mises en production pendant l'hypercare. Sans Service Desk, les tickets déjà rattachés restent lisibles, mais aucun ne peut être ajouté.

Les notes de version

Dans la carte Notes de version, Rédiger ouvre l'éditeur Markdown avec un Aperçu. Les titres, listes, gras, liens et tableaux sont rendus ; le HTML brut n'est pas interprété. Les notes s'exportent en Markdown ou en PDF.

Quand l'assistant IA est configuré, Brouillon à partir des changements propose un texte rédigé à partir des changements inclus. Il remplace le texte actuel après confirmation et n'est enregistré qu'avec Enregistrer. Quand l'IA est désactivée, ce bouton n'apparaît pas ; la rédaction manuelle reste possible.

Vues d'ensemble

• Calendrier des mises en production : les fenêtres de déploiement et les périodes de gel ; Afficher les changements ajoute les changements planifiés pour ceux qui peuvent les lire.
• Kanban des mises en production : une colonne par statut ; glisser une carte applique la transition avec les mêmes conditions que la fiche. La clôture et l'annulation se font depuis la fiche ; la colonne Clôturée montre les 30 derniers jours.
• Le widget Responsable des mises en production du tableau de bord affiche les mises en production en cours, les instances en retard et les taux d'échec et de rollback sur 90 jours.

Si le calendrier ou le Kanban n'est pas disponible sur votre instance, un message invite à utiliser la liste.