Processus de déploiement d'une build Windchill Navigate
Le processus de déploiement implique la soumission et la promotion de lots dans différents environnements. L'objectif est de s'assurer que le lot est minutieusement testé et validé à chaque étape avant d'atteindre l'environnement de déploiement final.
Le processus de déploiement de Navigate comprend les étapes suivantes :
1. Déploiement initial dans un environnement inférieur
2. Etape de la courbe de maturité
3. Déploiement final dans l'environnement de production
Prenons le scénario suivant : votre équipe sélectionne un cas d'utilisation en fonction des exigences actuelles, puis l'intègre dans le cycle de sprint. Le processus implique la soumission et la promotion de votre lot à travers différentes étapes. Initialement, vous déployez votre lot dans un environnement inférieur en le soumettant. Votre lot est promu à l'étape de la courbe de maturité. La promotion finale a lieu lors de l'étape de déploiement finale.
Description détaillée du processus
1. Premier déploiement de build/déploiement initial de build : le déploiement initial de build que PTC reçoit du client est soumis à une validation approfondie par l'équipe PTC. Les artefacts requis pour cette validation comprennent :
◦ Questionnaire complété : un questionnaire détaillé rempli par le client.
◦ Lot de build : lot compressé envoyé par les clients/intégrateurs système.
 | La build initiale ne passe à l'étape suivante que si l'équipe PTC l'approuve, garantissant ainsi qu'elle respecte les directives requises. |
2. Etape de courbe de maturité : cette étape ne requiert pas l'approbation de l'équipe PTC. Au cours de cette étape, la build passe par une courbe de maturité, qui inclut les tâches suivantes :
◦ Corrections de bogue : identification et résolution des problèmes.
◦ Modifications de logique : affinement de la fonctionnalité de la build.
◦ Test d'acceptation de l'utilisateur (UAT) : vérification que la build répond aux exigences de l'utilisateur.
◦ Modifications cosmétiques : ajustement de l'interface utilisateur et de l'expérience utilisateur.
Le déploiement initial s'effectue dans un environnement de non-production. Un client ou un intégrateur système est responsable de la conservation d'une documentation complète de toutes les modifications apportées à la build.
| | Il est essentiel que les exigences satisfaites par le lot de build et les dépendances de build (sur les bibliothèques tierces) restent inchangées au cours de ce processus. Si des modifications interviennent, vous devez redémarrer le processus de déploiement. |
3. Déploiement final de build dans l'environnement de production : le déploiement final sur le serveur du produit est soumis à une validation approfondie et complète par l'équipe PTC. Cette validation permet de s'assurer que tous les aspects de la build répondent aux normes les plus élevées en matière de qualité, de fonctionnalité et de conformité avant sa publication dans l'environnement de production. Les artefacts requis pour cette validation comprennent :
◦ Questionnaire complété : un questionnaire détaillé rempli par le client.
◦ Lot de build : lot compressé envoyé par les clients/intégrateurs système.
◦ Documentation détaillée : documentation complète de toutes les modifications apportées à la build au cours de l'étape de maturité. Pour plus d'informations, consultez la section Création d'une documentation complète : directives clés.
| | Cette étape requiert l'approbation de l'équipe PTC. |
Directives à l'intention des clients
• Cohérence des exigences : la build initiale que vous chargez doit contenir tout le contenu significatif. Il est essentiel pour l'intégrateur système d'éviter d'introduire des modifications importantes dans les exigences ou les dépendances (en particulier sur les bibliothèques tierces) au cours des deux étapes de déploiement : la première et la troisième étape.
• Documentation complète : vous devez conserver une documentation complète de toutes les modifications apportées à la build.
• Validation par l'équipe PTC : l'équipe PTC examine toutes vos modifications avant que la build ne soit promue en vue d'un déploiement final dans l'environnement de production.
En respectant ces instructions, vous pouvez garantir un processus de déploiement sécurisé et stable pour votre build Windchill Navigate.
A quelle fréquence devez-vous répéter le processus de déploiement ?
Lorsque vous envisagez une personnalisation, vous devez vous appuyer sur un cas d'utilisation spécifique et faire appel à une équipe de développement qui utilise des cycles de sprint. Votre équipe sélectionne un cas d'utilisation, qui peut être une exigence ou un ensemble d'exigences, et commence à le développer dans des cycles de sprint. Plusieurs cycles de sprint peuvent parfois être nécessaires pour préparer la build.
Par exemple, dans un cycle de publication de six mois comportant cinq sprints, les exigences sont sélectionnées et développées au cours de ces sprints. Vous pouvez avoir différentes séquences chronologiques, telles que des sprints de 20 jours avec des phases de développement, d'assurance qualité et de déploiement. Si les exigences changent de manière significative au cours du cycle, le processus doit redémarrer et des approbations sont requises.
La fréquence du processus de déploiement dépend du nombre de cas d'utilisation et de cycles de sprint. Par exemple, si vous développez 10 cas d'utilisation en 10 cycles de sprint, le processus est suivi 10 fois. Si vous développez 5 cas d'utilisation dans 1 cycle de sprint, le processus est suivi 2 fois.
Autres exemples :
1. Exemple 1 : Cycles de sprint plus courts
◦ Vous avez un cycle de sprint de 2 semaines. Vous sélectionnez une exigence, vous la développez pendant 10 jours, vous consacrez 2 jours à l'assurance qualité, puis vous la déployez. Si vous avez 6 exigences, vous suivez le processus 6 fois en 12 semaines.
2. Exemple 2 : Chevauchement d'exigences
◦ Vos exigences se chevauchent et s'étendent sur plusieurs sprints. Par exemple, une exigence qui nécessite 3 sprints suit le processus 1 fois pour chaque sprint, garantissant ainsi une intégration et des tests continus.
3. Exemple 3 : Modifications majeures en milieu de cycle
◦ Si vous apportez une modification importante à une exigence en milieu de cycle, telle qu'une modification du modèle de données, vous devez redémarrer le processus. Cela permet de réévaluer toutes les dépendances et d'obtenir les approbations.
4. Exemple 4 : Déploiements fréquents
◦ Vous préférez les déploiements fréquents et disposez de 1 cycle de sprint de 1 semaine. Vous développez pendant 4 jours, effectuez l'assurance qualité pendant 1 jour et déployez le dernier jour. Avec 8 exigences, vous suivez le processus 8 fois en 8 semaines.
5. Exemple 5 : Séquences chronologiques personnalisées
◦ Vous définissez des séquences chronologiques personnalisées en fonction des besoins de votre projet. Par exemple, vous pouvez avoir un cycle de sprint de 30 jours avec 20 jours de développement, 5 jours d'assurance qualité et 5 jours de déploiement. Vous ajustez la fréquence du processus en fonction du nombre d'exigences et de leur complexité.
Quelles sont les informations incluses dans le questionnaire ?
Vous devez remplir deux questionnaires au cours du processus de déploiement :
1. Questionnaire de déploiement initial : ce questionnaire est requis pour le premier déploiement dans un environnement inférieur. Il s'assure que toutes les vérifications et configurations préliminaires sont en place avant d'aller de l'avant.
2. Questionnaire de déploiement final : ce questionnaire est requis pour le déploiement final dans l'environnement de production. Il vérifie que tous les aspects critiques ont été examinés et approuvés, garantissant ainsi un déploiement fluide et réussi.
Voici un exemple de questionnaire :
Question | Réponse | |
|---|---|---|
Détails généraux | Votre nom de compte client | |
Votre version de Windchill | ||
Votre version de Windchill Navigate | ||
Votre date de déploiement prévue | ||
Votre environnement de déploiement prévu | ||
Détails du lot | Avez-vous testé ce lot dans des environnements inférieurs ? (Si oui, nommez l'environnement) | |
Quel type de personnalisation avez-vous implémenté ? | ||
Des bibliothèques tierces sont-elles utilisées dans ce lot ? | ||
Utilisez-vous la méthode d'authentification par défaut ou ce lot repose-t-il sur des clés d'application ? | ||
Quelle est la justification ou l'objectif visé par cette personnalisation ? | ||
Vous êtes-vous assuré qu'aucune partie de la personnalisation n'enfreint les protections ? | ||
Quelles sont les différences entre l'ancien et le nouveau lot (le cas échéant) ? |
| | Dans ce questionnaire, vous devez décrire les différences entre les anciens et les nouveaux lots. Par exemple, vous pouvez expliquer si de nouvelles fonctionnalités ont été ajoutées, si des bogues ont été corrigés ou si le numéro de version a été modifié. Ces différences sont importantes, car elles permettent de s'assurer que toutes les personnes impliquées dans le processus de déploiement comprennent ce qui a changé. Cela permet d'éviter les problèmes, de garantir la compatibilité et de s'assurer que le nouveau lot répond à toutes les exigences. |
Création d'une documentation complète : directives clés
Lorsque vous soumettez la build finale pour le déploiement dans l'environnement de production, il est essentiel d'inclure une documentation complète de toutes les modifications apportées au cours de l'étape de maturité. Cette documentation doit détailler toutes les mises à jour, tous les ajouts de fonctionnalités, toutes les corrections de bogues et toutes les révisions effectuées au cours du processus de développement.
En fournissant une documentation complète, vous vous assurez que toutes les parties prenantes sont au courant des modifications, ce qui aide à résoudre les problèmes, à maintenir la cohérence et à vérifier que la build répond à toutes les exigences. Cette étape est essentielle pour un déploiement fluide et réussi, car elle minimise le risque d'erreurs et garantit que l'environnement de production est entièrement préparé pour la nouvelle build.
Prenons le scénario suivant :
En règle générale, vous démarrez un cycle de build avec la version 1.0. Lorsque vous révisez la build dans les étapes suivantes, vous pouvez la mettre à jour vers des versions telles que 1.1, 1.2, etc. Lorsque la build est prête à être déployée sur le serveur de production, il est possible qu'elle ait été révisée à plusieurs reprises pour atteindre une version finale telle que 1.7.
Vous devez conserver un enregistrement détaillé des modifications effectuées au cours de chaque révision. Par exemple, si vous modifiez 5 éléments, documentez ces modifications de façon claire. Cette documentation peut se présenter sous la forme de notes de mise à jour, dont la taille varie selon le produit.
Par exemple, la documentation peut inclure :
• Version 1.4.6 : ajout d'un correctif pour gérer un problème spécifique.
• Version 1.4.5 : implémentation d'une nouvelle fonctionnalité.
• Version 1.4.4 : amélioration des performances pour une fonction particulière.
Ce type de documentation permet de suivre le parcours de la build de la version 1.0 à la version 1.7. Vous pouvez utiliser des captures d'écran ou tout autre format qui transmet le mieux les informations pertinentes. L'essentiel est d'assurer un suivi complet des modifications. Vous concevez le format en fonction de vos besoins, qu'il s'agisse d'un document Word, d'une feuille Excel ou de toute autre méthode.
Voici quelques exemples de journal des modifications :
Exemple 1 : Journal concis des modifications : résumé d'une ligne pour référence rapide
Exemple 2 : Journal détaillé des modifications : liste complète des mises à jour
Exemple 3 : Journal complet des modifications : compilation exhaustive des mises à jour, corrections et améliorations
