Démarrage rapide

Pour devenir rapidement productif avec IBM® UrbanCode Release, consultez les rubriques suivantes dans l'ordre.

Planification de l'édition

La planification de l'édition consiste à répondre à quelques questions élémentaires quant à sa portée. S'agit-il d'une édition totalement nouvelle ? Ou utilise-t-elle un plan défini auparavant ? S'agit-il d'une édition mineure, comme un correctif, qui ne requiert que des modifications minimes d'une édition existante ? Les réponses à ces questions déterminent votre trajectoire jusqu'à la production et la possibilité ou non de réutiliser une édition existante et, dans l'affirmative, à quel degré.

Remarque :

Veillez à ce que les entrées du train de l'édition proviennent d'une planification synchronisée et ouverte basée sur un travail d'équipe. L'objectif est de définir un ensemble clairement articulé de livrables et d'interdépendances.

La trajectoire vers la production fait référence à une succession de phases qui culminent sur la phase finale, c'est à dire la production. Sous sa forme la plus simple, une phase représente un ou plusieurs environnements et des exigences de qualité. Une phase peut comporter plus d'éléments, comme des statuts de qualité et des portes.

La progression des phases est définie par un modèle de cycle de vie. Lorsque vous créez une édition, les phases disponibles sont définies dans le modèle de cycle de vie sélectionné pour l'édition. Si une phase dont vous avez besoin n'est pas définie dans un cycle de vie, vous pouvez modifier le modèle ou en créer un autre entièrement nouveau. IBM UrbanCode Release fournit un cycle de vie par défaut que vous pouvez modifier à votre guise.

Le diagramme suivant illustre deux éditions, Octobre et Novembre, qui utilisent le même modèle de cycle de vie. Les phases qui sont définies dans le modèle sont affichés dans la partie supérieure. Des environnements sont alloués aux éditions et un environnement est affecté à chaque phase, comme illustré dans le diagramme. L'édition Octobre, par exemple, utilise l'environnement DEV-1 lors de la phase DEV, tandis que l'édition Novembre utilise l'environnement DEV-2 pour cette phase. Les portes entre les phases sont définies dans le modèle.

Diagramme présentant les phases et les portes de deux éditions

Un cycle de vie peut être utilisé pour n'importe quel nombre d'éditions. En diversifiant les environnements et les applications (notez que l'échelonnement des applications diffère entre les éditions), vous pouvez élaborer des éditions couvrant quasiment n'importe quelle éventualité à partir du même cycle de vie. Si un cycle de vie ne convient pas à une édition spécifique (par exemple, s'il comporte trop de phases ou pas assez), vous pouvez en créer un nouveau à n'importe quel moment.

Vous pouvez utiliser IBM UrbanCode Release pour jalonner la voie entre pré-production et production et exécuter de manière fiable les éditions le long du cheminement. Le train de l'édition peut être composé de n'importe quel type de matériel roulant (processus automatisés, manuels et ad hoc), et transporter n'importe quel type de fret. La calendrier planifié du train de l'édition pilote le processus de génération d'édition. En utilisant IBM UrbanCode Release, vous pouvez intégrer et synchroniser la planification basée équipe pour aboutir à un plan clair, ouvert et transparent. Toutes les parties prenantes connaissent le planning et peuvent être assurées du départ et de l'arrivée des éditions selon le calendrier.

Créez l'édition

Succinctement, la création d'une édition se réfère à l'utilisation de l'interface Web pour lui attribuer un nom et sélectionner un cycle de vie et une équipe. De manière plus générale, elle implique de déterminer s'il s'agit d'une édition majeure ou mineure. Empiriquement, une édition mineure désigne une édition utilisant des environnements et des applications existants, ou un sous-ensemble de ses applications, alors qu'une édition majeure requiert de nouveaux environnements et de nouvelles applications.

Associez des applications à l'édition

Bien que des applications ne soient pas impératives (vous pourriez créer une édition composée entièrement de jalons et de tâches associées à l'infrastructure), la grande majorité des éditions implique le déploiement d'applications. Les applications peuvent provenir d'une intégration avec des outils externes, tels qu'IBM UrbanCode Deploy, ou être créées dans IBM UrbanCode Release lui-même. Toutes les applications définies dans IBM UrbanCode Release sont disponibles pour chaque édition. Vous pouvez associer un nombre quelconque d'applications à une version.

Pour plus d'informations sur l'intégration d'IBM UrbanCode Release avec des outils externes, voir Configuration de fournisseurs d'intégration.

Définition du chemin jusqu'à la production

Les phases disponibles pour une édition sont définies dans le cycle de vie sélectionné pour celle-ci. Un modèle de cycle de vie peut être perçu comme un modèle utilisé pour créer et piloter des éditions. Un cycle de vie définit la succession de phases par lesquelles transite le logiciel jusqu'à son passage en production, lequel est représenté par une phase de production ou une autre phase ultime similaire. Le cycle de vie ne spécifie pas les environnements spécifiques utilisés pour une édition mais le canevas général. Par exemple, un cycle de vie pourrait être composé des phases suivantes : Développement, Assurance qualité et Production. Les éditions basées sur ce cycle de vie connaîtront donc ces trois phases, bien que les environnements utilisés concrètement puissent différer d'une édition à l'autre. Un cycle de vie peut également définir des étapes de qualité, dénommés portes, et devant être franchies pour que le logiciel puisse passer à la phase suivante.

Remarque :

Développez des stratégies adaptées à chaque phase. Des stratégies pour déploiements en production hautement formalisés peuvent être inadaptés à des environnements moins formels.

La première étape dans la définition du chemin jusqu'en production consiste à déterminer si un modèle de cycle de vie existant peut être utilisé ou si un modèle complètement nouveau s'impose. Si vous venez d'adopter IBM UrbanCode Release, vous devrez naturellement créer des cycles de vie qui reflètent vos processus et environnements usuels. Avec le fruit de l'expérience, vous pourrez développer un éventail de cycles de vie couvrant toutes vos éditions, ou leur majorité. Ainsi donc, les activités requises pour définir le chemin jusqu'à la production sont largement déterminées par la disponibilité de cycles de vie adéquats. Les tableaux suivants expliquent si un cycle de vie réutilisable est disponible pour diverses activités.

Tableau 1. Création d'un cycle de vie
Activité Description
1. Affectation d'un nom aux phases du cycle de vie.

Les environnements sont mappés à des phases.

2. Définition de statuts.

Les statuts sont des valeurs définies par l'utilisateur (par exemple, "Passage" ou "Archivé".

3. Ajout de portes.

Une porte est un mécanisme assurant que des éléments ne puissent pas être déployés dans une phase ou un environnement s'ils ne répondent pas un à statut de porte spécifié. Les portes stipulent des exigences d'entrée minimum dans une phase.

Tableau 2. Utilisation d'un cycle de vie
Activité Description
1. Allocation d'environnements aux phases.

Identifiez les environnements à utiliser au cours de chaque phase du cycle de vie. Un environnement d'édition désigne une construction définie par l'utilisateur et qui représente des cibles de déploiement. L'environnement d'édition agrège des environnements de déploiement.

2. Définition d'approbations.

Une approbation est un mécanisme utilisé pour contrôler des environnements sans prendre en compte des considérations de qualité ((état). Les valideurs sont désignés en spécifiant un rôle. Tout utilisateur affecté au rôle spécifié peut soumettre une approbation.

3. Sélection d'un plan de déploiement.

Un plan de déploiement définit le niveau d'orchestration et de coordination requis pour aboutissement d'un déploiement lors d'une phase spécifique.

Dates de production et de pré-production connues

Les dates de production et de pré-production connues peuvent être consignées et diffusées en planifiant des déploiements dans les environnements de l'édition.

Les dates sont définies lorsqu'un nouveau déploiement est planifié (Accueil > Déploiements planifiés ).

Créneaux récurrents

Un créneau récurrent, ou déploiement récurrent, peut être créé pour des déploiements qui se reproduisent à intervalle prévisible. Les créneaux récurrents peuvent être déclenchés sur une base horaire, quotidienne, hebdomadaire ou par une expression cron de tâche périodique.

Définissez des jalons

Les jalons désignent des activités (généralement figurant dans une liste de contrôle) qui doivent être réalisées pour que l'édition respecte son agenda. Un jalon peut correspondre à n'importe quel élément requérant un suivi, comme une réunion de lancement, une mise à niveau du système d'exploitation, du matériel ou du réseau. Les jalons sont suivis par date et statut.

Les jalons sont associés à l'édition elle-même et non pas à une phase ou un environnement spécifique. Les jalons son créés depuis la page Edition (Acceuil > Editions > édition_sélectionnée).

Remarque :

Même s'il peut être tentant de se concentrer sur les fonctions identifiées lors de la planification, restez vigilants de l'apparition potentielle de modifications susceptibles de changer la portée ou d'affecter le planning du train d'édition.

Définissez les équipes d'édition

Les équipes d'édition, comme il se doit, gèrent les éditions. Un équipe est composée de rôles et d'utilisateurs définis dans le système de sécurité d'IBM UrbanCode Release. Au moins un rôle doit avoir été configuré pour gérer une édition. Les rôles standard sont Admin, Gestionnaire d'édition et Utilisateur et sont tous disponibles par défaut. Les rôles peuvent être réutilisés.

Les rôles sont définis sur la page Rôles (Accueil > Gérer la sécurité > Rôles).

Ajoutez des approbations

Une approbation est un mécanisme utilisé pour contrôler des environnements sans prendre en compte des considérations de qualité ((état). Une édition qui requiert une approbation ne peut pas entamer une phase tant que l'approbation n'a pas été accordée. Les approbations sont rattachées à des phases. Les valideurs sont désignés en spécifiant un rôle. Tout utilisateur affecté au rôle spécifié peut soumettre une approbation.


Retour d'informations