Soumission et promotion de votre lot
Lorsque le lot CCD est prêt, utilisez le déploiement de build automatisé pour continuer. Le processus de déploiement de build automatisé implique d'orchestrer la promotion de votre configuration et la personnalisation conformément à vos droits et au paysage de l'environnement.
Vous pouvez soumettre une build en chargeant un lot CCD et un fichier de manifeste à leurs emplacements respectifs sur votre compte de stockage. Vous devez d'abord charger le lot CCD à l'emplacement /data/builds Vous devez ensuite charger le fichier de manifeste à l'emplacement /data/builds/deploy.
Cette action déclenche le processus de déploiement de build automatisé. Le processus est piloté par les tâches de notification reçues par e-mail. Les informations contenues dans l'e-mail vous guident tout au long des différentes étapes. Les approbateurs des tâches sont déclarés dans le fichier de manifeste. Un exemple de fichier de manifeste est disponible dans la rubrique Déclencher le déploiement automatisé.
 |
Tenez compte des points suivants comme conditions requises :
• Vous devez définir un emplacement de stockage BLOB Azure. Les détails de l'autorisation doivent être obtenus auprès du Cloud PTC.
◦ PTC fournit une URL SAS pour cette activité.
◦ Vous devez soumettre une demande auprès du portail du Support PTC pour que votre adresse IP figure dans la liste des adresses IP autorisées. Dans les détails de la requête, fournissez une adresse IP stable.
• Vous devez soumettre une demande de configuration de votre pipeline pour qu'il corresponde à la valeur mentionnée dans votre fichier de manifeste. int1 ou pipeline1 en sont des exemples. Pour plus d'informations sur l'attribut deploy_pipe, consultez la section Création d'un fichier de manifeste de la rubrique Déclencher le déploiement automatisé.
|
La première étape du processus de déploiement automatisé des builds est l'inspection du lot CCD. Le système examine le lot CCD pour s'assurer qu'il est conforme aux lignes directrices de Windchill+. Après l'inspection, le système génère les rapports et les rend disponibles sur le compte de stockage.
Vous pouvez consulter les rapports et les journaux à l'adresse suivante : /data/builds/logs/<RITM Number>/. La syntaxe des rapports et des fichiers journaux générés est la suivante :
• Syntaxe des rapports : cwave_<CustomerShortName>_<Date-Time>_<Control Label>.html. Dans cet exemple, <Control Label> peut être IntakeProcessor, SpotBugs, Logs, etc.
• Syntaxe des journaux : ccd_<environment>_<Date-Time>_<ant target>_Logs.zip. Dans cet exemple, <ant target> peut être deploy, load, etc. Pour plus d'informations, consultez la rubrique Targets.
|
Nom du rapport
|
Vérifications implémentées
|
|---|---|
|
cwave_<CustomerShortName>_<Date-Time>_IntakeProcessor.html
|
Vérifications Windchill+ (personnalisation Windchill+ autorisée, dépréciation, API non prises en charge, sécurité)
|
|
cwave_<CustomerShortName>_<Date-Time>_SpotBugs.html
|
Vérification de code statique (bonnes pratiques Java)
|
Examinez les points suivants :
• Si l'un des contrôles du lot CCD échoue, vous recevez une notification et le processus de soumission est interrompu.
• Si le lot CCD est conforme, le processus se poursuit et la build est promue vers la cible définie dans le fichier de manifeste.
• Une fois qu'un déploiement de build a réussi, vous disposez de sept jours pour terminer vos tests.
|
|
En tant que client, vous êtes responsable du contenu du lot CCD. En soumettant une build, vous certifiez que le développement a été réalisé conformément aux Directives de sécurité de PTC. Pour plus d'informations sur les Directives de sécurité de PTC, consultez la rubrique Security Customization Guidelines.
|
Protections de Windchill+ pour la composition d'un lot CCD
Votre lot CCD et sa composition doivent respecter une structure de répertoire spécifique. Suivez les protections fournies pour la structure des répertoires et le contenu des fichiers d'un lot CCD :
• La taille d'un lot CCD ne doit pas dépasser 100 Mo.
• Le lot CCD peut contenir les dossiers suivants :
|
Dossier
|
Description
|
|---|---|
|
Configurations
|
Aucun ou un dossier Configurations
|
|
Generated
|
Aucun ou un dossier Generated
|
|
customlib
|
Aucun ou un dossier customlib
|
|
<custom module(s)>
|
Un ou plusieurs dossiers de module personnalisés
|
|
|
Sur les quatre dossiers, au moins l'un d'entre eux doit figurer dans votre lot CCD.
|
• Le fichier descriptor.xml doit être présent dans tous les dossiers de module personnalisés de votre lot CCD.
• Le dossier Generated peut être vide ou contenir l'un ou l'autre des dossiers suivants, ou les deux :
◦ Dossier db : le dossier db peut être vide. Dans le cas contraire, il doit contenir le fichier db/conf/SchemaConfig.xml.
◦ Dossier BAC : un seul fichier .zip BAC est autorisé dans le dossier BAC. Les mappages BAC peuvent être fournis dans le fichier Mapping.xsl situé dans le dossier BAC.
◦ Le dossier customlib doit contenir les fichiers JAR d'adresses IP partenaires, le cas échéant.
• Les valeurs d'offre autorisées sont plusselect et meddev.
• Un lot CCD doit être exempt de fichiers bloqués ou inattendus, conformément aux règles suivantes :
◦ Liste de fichiers non autorisés dans le lot : .jar, .class, .exe, .ser, .sql, .ddl, .pks, .pkb, .ora, .jasper, .cs, .cpp, .so, .dll, .jnilib, .dylib, .h, .cgf, .out, .ldif, .sh,.pl, .groovy, .gwt.xml, .gwt.modules.xml
◦ Fichiers valides dans le dossier xconf : .xconf
◦ Fichiers valides dans le dossier conf : .xml, .ini
◦ Fichiers valides dans le dossier resources : .tpl, .bas, .ddx, .html, .yml, .xjb, .ftl, .xml, .dtd, .xsl, .properties, .txt, .ini, .json, .js
◦ Fichiers valides dans le dossier src : .java, .rbInfo
◦ Fichiers valides dans le dossier jsp : .jsp, .jspf
◦ Fichiers valides dans le dossier tags : .tag, .tagf
◦ Fichiers valides dans le dossier tlds : .tld
◦ Fichiers non autorisés dans le dossier src_web : .java
◦ Chemin valide pour le dossier JasperReports : module/main/resources et module/main/src_web (non valide au niveau des configurations)
◦ Fichiers valides dans le dossier JasperReports sur le chemin des ressources : .jrxml, .jasperProperties et .properties
◦ Type de fichier valide dans le dossier JasperReports sur le chemin src_web : .gif
◦ Fichiers valides dans le dossier customlib : .jar
◦ Les dossiers portant le nom apps ne sont pas autorisés dans les dossiers suivants :
▪ configurations/resources
▪ main/resources
▪ main/src_web
Ces protections sont vérifiées lorsque le lot est soumis pour déploiement. Toute non-conformité est signalée. Les journaux de déploiement contiennent un rapport récapitulatif RITM, par exemple, RITM0910921.txt. Ce rapport indique si le lot est conforme aux protections Windchill+. Voici un exemple de rapport récapitulatif RITM :
Vous trouverez les journaux détaillés RITM dans un fichier zip de rapport détaillé contenant les détails de vérification de ces protections. Ce fichier zip inclut un fichier journal qui fournit les détails de vérification des protections.
Exemple de fichier zip : RITM0910921_Reports.zip.
Exemple de fichier journal : preValidate_20240402-142645.log.
| | Bien que ces règles ne soient pas appliquées, vous devez prendre note de toutes les déviations et les corriger activement. PTC appliquera certaines de ces règles à l'avenir, et toute non-conformité rendra le lot non valide par la suite. Pour plus d'informations sur les personnalisations interdites et les avertissements, consultez la rubrique Disallowed Customization. |
Avant la mise en service
Vous pouvez utiliser Windchill+ sans l'environnement d'assurance qualité (AQ). Vous pouvez également utiliser Windchill+ avancé avec l'environnement d'assurance qualité. Selon le scénario, vous pouvez suivre les étapes mentionnées dans les approches suivantes :
Windchill+ avancé avec environnement d'assurance qualité
Procédez comme suit lorsque vous utilisez Windchill+ avancé avec l'environnement d'assurance qualité (AQ) :
1. Soumettez votre lot dans l'environnement d'intégration pour le cycle de test d'intégration et d'acceptation fonctionnelle. Vous pouvez déclencher ce cycle de test fréquemment. Par exemple, plusieurs fois par semaine.
◦ Soumettez une build et un fichier de manifeste avec deploy_pipe : int.
Pour plus d'informations, consultez la rubrique Deploying Code and Configuration Package (en anglais).
◦ Terminez le cycle de test. A la fin du cycle de test, la tâche est considérée comme terminée et l'environnement revient à son état précédent.
| | Si cette étape n'est pas effectuée dans les sept jours, l'environnement revient automatiquement à son état précédent. |
2. Soumettez votre lot à l'environnement d'assurance qualité pour l'UAT, puis promouvez-le vers l'environnement de production. Il est recommandé de déclencher le cycle de test UAT une à deux fois par mois, car ce processus promeut la build vers l'environnement de production.
◦ Soumettez une build et un fichier de manifeste avec deploy_pipe : pipeline. Pour plus d'informations, consultez la rubrique Deploying Code and Configuration Package (en anglais).
◦ Terminez le cycle de test. Examinez les points suivants :
▪ Si le cycle de test réussit, la tâche est approuvée et la build est promue vers l'environnement de production.
▪ Si le cycle de test échoue, la tâche est rejetée et l'environnement revient à l'état précédent.
▪ Si le cycle de test n'est pas terminé dans les sept jours, l'environnement revient à son état précédent.
Windchill+ de base sans environnement d'assurance qualité
Lorsque vous utilisez un système Windchill+ Select de base sans environnement d'assurance qualité (AQ), procédez comme suit :
1. Soumettez une build et un fichier de manifeste avec deploy_pipe : int. Pour plus d'informations, consultez la rubrique Deploying Code and Configuration Package (en anglais).
2. Terminez le cycle de test d'intégration et d'acceptation fonctionnelle. A la fin du cycle de test, la tâche est terminée et l'environnement revient à son état précédent.
| | Si cette étape n'est pas effectuée dans les sept jours, l'environnement revient à son état précédent. |
3. Resoumettez la même build et un fichier de manifeste mis à jour avec deploy_pipe : pipeline. Pour plus d'informations, consultez la rubrique Deploying Code and Configuration Package (en anglais).
4. Terminez le cycle de test d'acceptation de l'utilisateur sur l'environnement d'intégration. Examinez les points suivants :
◦ Si le cycle de test réussit : la tâche est approuvée et la build est promue vers l'environnement de production.
◦ Si le cycle de test échoue : la tâche est rejetée et l'environnement revient à l'état précédent.
◦ Si le cycle de test n'est pas terminé dans les sept jours, l'environnement revient automatiquement à son état précédent.
| | Toutes les activités de test utilisent un seul environnement. Le système ne peut effectuer qu'une seule activité de test à la fois. Si une build est soumise à l'aide de deploy_pipe : int pendant cette période, elle est automatiquement rejetée. |
Etape de mise en service
Une fois que vous avez confirmé l'étape de mise en service, il est obligatoire de réhéberger l'environnement de production dans les environnements d'assurance qualité et d'intégration.
Vous devez ouvrir une demande d'intervention sur le portail du Support PTC pour cette activité. Pour plus d'informations, consultez la rubrique Ouverture d'une demande d'intervention.
Etat d'exécution
• Une fois la mise en service réussie, tous les environnements sont réhébergés à partir de l'environnement de production. Par conséquent, PTC recommande vivement de propager les modifications dans les environnements de développement. L'approche recommandée consiste à utiliser BAC et à exporter un lot BAC complet à partir de l'environnement d'intégration. Pour plus d'informations, consultez rubrique Importing a BAC Package Using the CCD Utility.
Examinez les points suivants :
◦ Le modèle de données est le minimum que vous devez exporter pour régénérer votre système (gestionnaire d'attributs et de types).
◦ Pour les objets non pris en charge par BAC, vous pouvez exporter à partir de l'intégration depuis l'interface utilisateur (si possible) ou recréer le fichier de charge dans votre environnement de développement.
• Ensuite, le cycle de soumission est similaire à celui mentionné dans la section Avant la mise en service de la rubrique Soumission et promotion de votre lot.
• Après une mise en service majeure, vous devez réhéberger votre environnement de production dans les environnements d'assurance qualité et d'intégration. Une demande d'intervention doit être ouverte pour les activités de réhébergement. Pour plus d'informations, consultez la rubrique Ouverture d'une demande d'intervention.
| | • Après une mise en service initiale réussie, tous les environnements (à l'exception de l'environnement de développement) doivent être réhébergés à partir de la production. Ce réhébergement n'est pas automatique et nécessite une demande d'intervention. • La mise en service initiale désigne le premier déploiement de l'application dans l'environnement de production. A ce stade, tous les environnements de niveau inférieur sont synchronisés avec l'environnement de production afin de garantir cohérence et stabilité dans le paysage de déploiement. • Une mise en service majeure désigne toute version ultérieure de l'environnement de production après la mise en service initiale. Ces versions incluent généralement de nouvelles fonctionnalités, des améliorations ou des correctifs et font partie du cycle de développement et de livraison en cours. |