Créer et configurer des travaux de fabrication en production

Voici quelques informations à connaître avant de configurer et d'exécuter des travaux de build et des pipelines :

• Assurez-vous que les instances source et cible sont de la même version, avec les mêmes patches standard et ponctuels appliqués aux deux environnements.
• Si vous avez configuré le travail de packaging de développement pour écraser la version de l'application définie dans visual-application.json, obtenez la nouvelle version. Vous allez configurer le travail de packaging de la production pour qu'il utilise la même version.
• VB Studio peut créer et activer les travaux de build et le pipeline pour vous. Dans l'éditeur de paramètres de l'extension, sous Création et publication, sélectionnez la branche de production, puis cliquez sur Créer un pipeline d'intégration continue et de déploiement continu. Vous pouvez ensuite modifier les travaux de build nouvellement créés si nécessaire. Par exemple, dans le travail de déploiement, la cible de déploiement est toujours l'environnement associé à l'espace de travail. Vous devrez donc remplacer l'instance cible par l'instance de production.

Le travail de packaging génère un artefact d'extension prêt à être déployé sur l'instance de production.

1. Dans le navigateur de gauche, cliquez sur Builds .
2. Dans l'onglet Travaux, cliquez sur + Créer un travail.
3. Dans la boîte de dialogue Nouveau travail, dans Nom, entrez un nom unique.
4. Dans Description, entrez la description du travail.
5. Dans Modèle, sélectionnez le modèle OL7 par défaut du système pour Visual Builder.
6. Cliquez sur Créer.
7. Cliquez sur Configurer .
8. Cliquez sur l'onglet Git.
9. Dans la liste Ajouter un Git, sélectionnez Git.
10. Dans Référentiel, sélectionnez le référentiel Git. Dans Branche ou balise, sélectionnez la branche de production.
11. Cliquez sur l'onglet Etapes.
12. Dans Ajouter une étape, sélectionnez Extension d'application, puis Package.
13. Par défaut, l'étape de packaging minifie le code source de l'application avant d'exécuter le build. Si vous ne voulez pas réduire les fichiers source, désélectionnez la case Optimiser l'extension.

    La minimisation est un processus qui permet de supprimer les caractères inutiles (tels que les espaces vides, les nouvelles lignes et les commentaires) du code source et de réduire la taille des fichiers, ce qui réduit la consommation de bande passante et de stockage.

    Remarque
    
    Lorsque vous désélectionnez la case Optimiser l'extension, l'avertissement suivant s'affiche : Optimisation non sélectionnée. Un packaging sans optimisation peut entraîner des problèmes de performances. Ainsi, évitez d'y avoir recours, sauf si vous effectuez un débogage ou un dépannage.
14. (Facultatif) Si vous souhaitez modifier le nom du fichier d'artefact, entrez le nouveau nom dans Créer un artefact. La meilleure pratique consiste à conserver la valeur par défaut, extension.vx, mais vous pouvez la modifier.
    Si vous le modifiez, vous devez également utiliser le nouveau nom dans le champ Fichiers à archiver (étape 18), ainsi que dans le champ Créer un artefact du travail de déploiement. Reportez-vous à Création du travail de build de déploiement de production.
15. (Facultatif) Si vous avez configuré le travail de packaging de développement pour remplacer la version par défaut de l'extension définie dans le fichier visual-application.json, indiquez la même version dans Version d'extension.
16. Cliquez sur l'onglet Après la création dans la fenêtre Configuration du travail.
17. Dans Ajouter après l'action de build, sélectionnez Archiver d'artefacts.
18. Dans Fichiers à archiver, entrez le nom de l'artefact de build.

    Vous pouvez utiliser des caractères génériques. Par exemple, *.vx. Veillez à inclure le chemin de l'artefact de build d'extension d'application.

    Si vous avez saisi une valeur dans le champ Répertoire cible de Copier les artefacts pour le travail de déploiement, il est considéré comme un sous-répertoire de l'espace de travail et doit faire partie du chemin de l'artefact dans le champ Créer un artefact.

19. Pour ignorer les anciens artefacts du build, cliquez sur Paramètres . Dans l'onglet Général, cochez la case Rejeter les anciens builds et indiquez les options de rejet.
20. Cliquez sur Enregistrer.

Le travail de déploiement déploie l'artefact de l'extension généré dans le travail de packaging vers l'instance de production de l'application Oracle Cloud. Avant de créer le travail, assurez-vous que vous disposez des informations d'identification que VB Studio peut utiliser pour accéder à l'instance PROD de l'application Oracle Cloud.

1. Dans le navigateur de gauche, cliquez sur Builds .
2. Dans l'onglet Travaux, cliquez sur + Créer un travail.
3. Dans la boîte de dialogue Nouveau travail, dans Nom, entrez un nom unique.
4. Dans Description, entrez la description du travail.
5. Dans Modèle, sélectionnez le modèle OL7 par défaut du système pour Visual Builder.
6. Cliquez sur Créer.
7. Cliquez sur Configurer .
8. Cliquez sur l'onglet Avant la création.
9. Dans Ajouter avant l'action de build, sélectionnez Copier les artefacts.
10. Dans A partir du travail, sélectionnez le travail de packaging qui a généré l'artefact de l'extension.
11. Dans Quel build, sélectionnez l'une des options suivantes :
    • Dernier build réussi (valeur par défaut)
    • Dernier build conservé indéfiniment
    • Build en amont dans cette instance de pipeline
    • Indiqué par un lien permanent
    • Build spécifique
    • Indiqué par un paramètre de build

    Selon ce que vous sélectionnez, vous pouvez être invité à sélectionner le permalien, le paramétrage ou le paramètre de paramétrage que vous voulez utiliser.
12. Laissez les autres champs avec leurs valeurs par défaut ou vides.
13. Cliquez sur l'onglet Etapes.
14. Dans Ajouter une étape, sélectionnez Extension d'application, puis Déployer.

    Cette image présente la page Déployer un travail de build partiellement remplie.
    
    Description de l'illustration oracle-deploy-build-step.png
    

15. Dans Instance cible, sélectionnez l'environnement avec l'instance de production de l'application Oracle Cloud.
16. Dans la section Autorisation, indiquez le type d'autorisation pour exécuter cette étape de paramétrage. Lorsque l'option Utiliser OAuth est sélectionnée par défaut, le message Authorization is required apparaît, indiquant que cette étape de build nécessite une autorisation unique pour gérer les demandes OAuth vers l'instance Oracle Cloud Applications de votre environnement. Cliquez sur Autoriser et entrez les informations d'identification pour accéder à votre instance Oracle Cloud Applications. Vous pouvez également exécuter le travail manuellement et entrer les informations d'identification lorsque vous y êtes invité.

    Dans tous les cas, il est recommandé d'autoriser la connexion OAuth lors de la configuration initiale. Si vous ignorez cette étape, vous ne pourrez pas publier vos modifications à partir du concepteur et devrez terminer l'autorisation requise avant de tenter de déployer les modifications.

    Une fois autorisé, le message Authorization has been provided s'affiche.

    Remarque
    
    OAuth est le type d'autorisation recommandé. Utilisez l'authentification de base uniquement si vous rencontrez des problèmes lors de la configuration d'une connexion OAuth. Pour utiliser l'authentification de base, sélectionnez Utiliser de base, puis entrez les informations d'identification d'un utilisateur qui peut accéder à l'instance Oracle Cloud Applications dans Nom utilisateur et Mot de passe. Ces informations d'identification doivent être celles d'un utilisateur local, et non d'une identité fédérée, et ne doivent pas nécessiter d'authentification à plusieurs facteurs.

    Les jetons OAuth (accès et actualisation) sont cyclés lors d'une utilisation régulière. Un jeton d'actualisation est utilisé pour obtenir un jeton d'accès chaque fois qu'un utilisateur accède à l'instance cible. Ce jeton d'actualisation est généralement valide pendant sept jours. (Le délai d'expiration du jeton est défini dans l'application de ressource IDCS et peut être différent en fonction de vos exigences de sécurité.) Si l'utilisateur s'authentifie auprès de l'instance cible pendant la période de sept jours, le jeton d'actualisation actif génère un nouveau jeton d'accès et un nouveau jeton d'actualisation. Ce cycle se poursuit indéfiniment tant que le jeton d'actualisation reste valide. Si le jeton d'actualisation expire pendant de longues périodes d'inactivité (par exemple, lorsque vous êtes absent en vacances), cliquez sur Renouveler l'autorisation (ou exécutez le travail manuellement, de sorte que vous êtes invité à autoriser les jetons OAuth expirés).

    Le champ Créer un artefact doit afficher le même nom d'artefact que celui utilisé dans l'étape de création de package. Confirmez cette valeur, en particulier si le travail de packaging a utilisé un nom d'artefact autre que celui par défaut, extension.vx.
17. Cliquez sur Enregistrer.

Pour restreindre l'accès, le propriétaire du projet peut marquer un travail comme privé. Les utilisateurs qui n'y ont pas accès peuvent voir le travail de build sur la page Présentation des travaux, mais ils ne peuvent pas voir la page Détails du travail ni visualiser les détails du build. Ils ne peuvent pas non plus voir ou modifier la configuration du travail, ni supprimer/activer/désactiver le travail de build. En outre, le propriétaire du projet peut utiliser un modèle glob défini dans une règle pour protéger tout travail dont le nom correspond au modèle spécifié.

1. Dans le navigateur de gauche, cliquez sur Administration de projet .
2. Sélectionnez la mosaïque Builds.
3. Sélectionnez l'onglet Protection des travaux.

   La page Job Protection s'affiche.

   
   
   Description de l'image job-protection-page-initial.png
   

4. Dans le panneau Rechercher les règles par, situé au-dessus de la liste des tâches/règles, sélectionnez l'un des boutons radio suivants :
   • Sélectionnez Nom de travail pour choisir un travail dans la liste.

     Si votre projet a de nombreux emplois, vous pourriez avoir de la difficulté à trouver le travail spécifique que vous souhaitez protéger. Utilisez la barre du travail de filtrage pour localiser rapidement le travail auquel vous voulez ajouter les paramètres restreints.

     Cliquez avec le bouton droit de la souris sur la liste des tâches pour afficher des options de tri supplémentaires. Cliquez sur Trier par nom de travail ou sur Trier par travail privé pour trier la liste en conséquence. Cliquez à nouveau sur l'option de tri pour basculer entre l'ordre croissant et l'ordre décroissant.

     
     
     

     Si un travail a une icône de verrou , il a déjà été protégé. Les restrictions d'un travail protégé peuvent toujours être modifiées, supprimées ou la liste des utilisateurs et des groupes autorisés peut toujours être modifiée.

     La boîte de dialogue Protection des travaux s'affiche.

     
     
     Description de l'image job-protection-open.png
     

     Lorsqu'un travail n'est pas protégé directement mais est protégé par une règle, un message d'information tel que le suivant affiche les règles <ExampleRegex05> qui protègent le travail spécifique :

     This job is protected by the following glob pattern rules matching this job name: <ExampleRegex05>

   • Sélectionnez Modèle global pour spécifier une chaîne qui correspond au nom du travail.

     C'est ce que vous verrez si aucune règle n'a encore été définie.

     
     
     Description de l'image job-protection-page-glob-pattern-selected.png
     

     La syntaxe glob peut être utilisée pour spécifier un comportement de correspondance de modèle. Ces caractères génériques peuvent être utilisés dans les modèles glob : *, **, ?, [], {} et \.

     Sélectionnez une règle de protection existante dans la liste ou cliquez sur + Règle pour afficher la boîte de dialogue Nouvelle règle de protection et en créer une nouvelle.

     La boîte de dialogue Règle de protection s'affiche.
     
     Description de l'illustration protection-rule-dialog-populated.png
     Nous avons entré un nom (règle de test) et un modèle glob (test*). Nous sommes sur le point d'appuyer sur Créer pour créer une règle de protection de travail.

5. Cochez la case PRIVATE.
   C'est ce que vous voyez après avoir sélectionné l'option Privé pour un travail.

   
   
   Description de l'image job-protection-private.png
   

   Lorsque cette option est sélectionnée, seuls les utilisateurs et les groupes autorisés pourront afficher la page Détails de travail, ainsi que modifier le travail ou l'exécuter manuellement. Si le travail est déclenché dans un pipeline par un utilisateur ou groupe non autorisé, ou s'il est déclenché par SCM ou l'horloge, il n'est pas lancé.

   C'est ce que vous voyez après avoir sélectionné l'option Privé pour une règle de protection.

   
   
   Description de l'image job-protection-rule-private.png
   

6. Cliquez dans le champ Utilisateurs/groupes autorisés pour afficher une boîte de dialogue répertoriant les groupes et les utilisateurs du projet que vous pouvez sélectionner.

   Sous Utilisateurs, vous pouvez voir une liste réduite de tous les utilisateurs qui sont membres du ou des groupes, ainsi que de ceux qui ont été ajoutés individuellement. Par exemple, les membres du groupe de développement (Clara Coder, Don Developer et Tina Testsuite) apparaissent dans la liste Users, ainsi que Alex Admin, qui a été ajouté individuellement. Dans la liste, sélectionnez un ou plusieurs groupes et/ou utilisateurs. N'oubliez pas de vous ajouter.

   
   
   Description de l'image allowed-groups-users.png
   

   Voici ce que vous pouvez voir pour le travail myProtectedJob après avoir sélectionné l'administrateur Alex en tant qu'utilisateur autorisé.

   
   
   Description de l'image job-protection-private-authorized-user.png
   

   C'est ce que vous verrez pour la règle de protection Règle de test après avoir sélectionné Alex Admin en tant qu'utilisateur autorisé.

   
   
   Description de l'image job-protection-rule-authorized-user.png
   

7. Cochez les cases pour autoriser les membres du projet à démarrer manuellement des travaux privés et/ou autoriser les validations et les déclencheurs à démarrer automatiquement des travaux privés :

   • Cochez la case Autoriser les membres du projet à démarrer manuellement ce travail privé pour autoriser tous les membres du projet, et pas seulement les utilisateurs autorisés, à démarrer manuellement ce travail.

     Voici ce que vous verrez après avoir coché la case Autoriser tout membre du projet à démarrer manuellement ce travail privé pour le travail myProtectedJob.

     
     
     Description de l'image job-protection-private-both-checkboxes-selected.png
     

     Notez que lorsque vous cochez la première case, VB Studio sélectionne automatiquement la deuxième case, ce qui permet aux validations et aux déclencheurs de démarrer le travail privé, et le grise. Avec ce paramètre, seuls les utilisateurs et groupes autorisés peuvent afficher la page Détails du travail ou modifier le travail, mais tout membre du projet peut démarrer et exécuter le travail. En outre, les validations ou les déclencheurs SCM démarrent et exécutent automatiquement le travail.

     Voici ce que vous verrez après avoir coché la case Autoriser tout membre du projet à démarrer manuellement ce travail privé pour la règle de protection Règle de test.

     
     
     Description de l'image job-protection-page-both-check-boxes.png
     

   • Cochez uniquement la case Autoriser les validations et les déclencheurs à démarrer ce travail privé si vous souhaitez que les validations et les déclencheurs SCM puissent exécuter automatiquement ce travail.

     
     
     Description de l'image job-protection-private-allow-commits-triggers.png
     

     Lorsque cette case est cochée, les déclencheurs périodiques exécutent n'importe quel travail ou pipeline, y compris les travaux privés définis pour autoriser les validations et les déclencheurs à démarrer le travail privé. Toutefois, si un pipeline inclut un travail privé avec cette option sélectionnée et qu'un utilisateur non autorisé tente d'exécuter le pipeline manuellement, le travail privé ne sera pas exécuté, mais des déclencheurs périodiques et des validations SCM le seront.

     Ne cochez pas la case si vous ne voulez pas que le travail soit démarré lorsqu'il est déclenché par une validation ou une minuterie SCM.

     Remarque
     
     

     Meilleures pratiques :

     Si vous utilisez la case à cocher pour activer le déclenchement du build protégé par une validation SCM, vous devez protéger le branchement auquel le travail de build est lié. Si vous ne le faites pas, n'importe qui peut déclencher le build protégé en effectuant une validation pour le déclencher.

     C'est ce que vous voyez si vous avez sélectionné l'option Autoriser les validations et les déclencheurs à démarrer tout travail correspondant à ce modèle glob pour la règle de test.

     
     
     Description de l'image job-protection-page-allow-commits-triggers.png
     

8. Cliquez sur Enregistrer.

   Le flux d'activités affiche toutes les modifications apportées au statut de protection d'un travail, telles que la modification de la protection d'un travail de public à privé, ou privé à public, ou la modification d'un travail privé pour autoriser les validations et les déclencheurs.