Les éditions sont implémentées par des déploiements. Un déploiement cible une seule phase et l'environnement associé (chaque phase a un seul environnement qui lui est associé). Un déploiement peut être de grande envergure et utiliser toutes les applications d'une édition, représenter un déploiement d'urgence et ponctuel d'une seule application, ou n'importe quelle variante intermédiaire. Les déploiements peuvent être ciblés aussi précisément que nécessaire.
Les déploiements d'IBM® UrbanCode Release conjuguent :
Le planning qui définit quand le déploiement doit intervenir et s'il s'agit d'une événement ponctuel ou récurrent
Des notifications par courrier électronique déclenchées par des événements définis par l'utilisateur et envoyées à un utilisateur ou à un rôle utilisateur spécifique
Les approbations requises
Le déploiement, ou les plans de déploiement, sont composés de segments. Un segment représente des activités d'édition destinées à être réalisées ensemble. Un segment peut être configuré pour être exécuté après l'aboutissement d'un autre segment ou indépendamment d'autres segments. Un plan de déploiement peut comporter un nombre quelconque de segments. Le plan par défaut est composé de deux segments : Tâches de pré-déploiement et Tâches de déploiement.
Une fois qu'un plan de déploiement a été défini, un déploiement peut être déclenché à n'importe quel moment via une demande de déploiement. Une demande de déploiement peut lancer un déploiement complet ou une portion du plan (par exemple, un segment individuel).
Veillez à ce que chaque équipe dispose d'un plan de secours en plus du plan principal. Le plan de secours peut être aussi simple qu'une rétromigration vers une ancienne version jusqu'à ce que les blocages aient été résolus.
Comme son nom l'indique, un déploiement ad hoc désigne un déploiement non planifié. Des déploiements ad hoc peuvent être entrepris n'importe quand et donc vous n'avez pas besoin de définir une liste de déploiements exhaustive lors de la planification de l'édition.
Le test dans une succession d'environnements usuels est important, notamment des fenêtres récurrentes ; toutefois, gardez assez de souplesse pour pouvoir réaffecter des environnements si ceux prévus ne sont pas disponibles.
Généralement, l'alignement des applications est défini lorsque l'édition est créée. Les applications associées à l'édition sont automatiquement disponibles pour tout déploiement qui utilise l'édition. Les applications et suites d'applications peuvent être promues au statut de versions publiées. Généralement, une version publiée représente une application (ou une suite) qui a été déployée avec succès et peut être réutilisée de manière fiable.
De plus, vous pouvez ajouter des applications à une édition après que des déploiements aient été planifiés pour celle-ci. Les nouvelles applications prennent part au déploiement à venir ou en cours.
Les activités de déploiement sont définies par des tâches. Une tâche individuelle est une unité de travail pouvant représenter n'importe quelle activité métier significative associée à une édition. Les tâches peuvent être configurées pour s'exécuter une seule fois, ou chaque fois que le plan de déploiement est utilisé. Une tâche peut être affectée à un rôle utilisateur ou à un utilisateur spécifique ; si elle n'est pas attribuée, tout utilisateur affecté au rôle requis peut se l'adjuger. Une fois qu'une tâche est définie, elle est ajoutée à la bibliothèque des tâches et devient disponible pour d'autres déploiements.
Lorsqu'une tâche est créée, une durée lui est attribuée, c'est à dire une estimation du temps nécessaire à son exécution. IBM UrbanCode Release agrège les durées des tâches pour calculer la durée totale du déploiement.
Les tâches peuvent être automatisées ou manuelles. Les tâches automatisées proviennent des intégrations avec des outils externes. Des processus d'application IBM UrbanCode Deploy, par exemple, sont disponibles en tant que tâches automatisées dans IBM UrbanCode Release.
Les tâches manuelles peuvent correspondre à n'importe quelle tâche non automatisée (par exemple, l'arrêt ou le démarrage d'un serveur). Contrairement aux jalons qui sont définis pour l'édition globale, les tâches manuelles (et les tâches automatisées) sont rattachées à une phase et à un segment spécifiques. Un segment peut être considéré comme un groupe de tâches censées se terminer en même temps.
Généralement, les tâches sont définies sur la page Déploiements planifiés dans l'application Web, mais elles peuvent également être exportées et importées (sous forme de fichiers CSV).
Les versions d'application peuvent être associés à des statuts de qualité. Ces statuts permettent de s'assurer que les versions d'application répondent aux critères de qualité prévus. Les statuts peuvent être attribués manuellement ou via l'intégration avec des outils externes.
Les approbations et les portes peuvent être temporairement suspendues lorsqu'un déploiement d'urgence est requis.
Une approbation est un mécanisme utilisé pour contrôler des environnements sans prendre en compte des considérations de qualité (statut). Les approbations sont rattachées à des phases. Une édition qui requiert une approbation ne peut pas entamer une phase tant que l'approbation n'a pas été accordée. Les valideurs sont généralement désignés en sélectionnant un rôle utilisateur. Tout utilisateur avec le rôle désigné peut répondre à une demande d'approbation. Si, par exemple, la phase Assurance qualité requiert l'approbation d'un gestionnaire d'édition, cette phase ne peut pas débuter tant qu'une approbation n'a pas été obtenue d'un utilisateur affecté à ce rôle. Des utilisateurs spécifiques peuvent également être désignés pour émettre une approbation.
Si un déploiement planifié qui requiert une approbation atteint son calendrier d'exécution sans avoir reçu cette approbation, la phase ne débute pas et est considérée avoir été rejetée par le valideur.