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 exceptionnels appliqués aux deux environnements.
• Si vous avez configuré le travail de package de développement pour écraser la version de l'application définie dans visual-application.json, obtenez la nouvelle version. Vous configurerez le travail de packaging de la production pour qu'il utilise la même version.

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

1. Dans le navigateur de gauche, cliquez sur Constructions .
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 Valeur par défaut du système OL7 pour Visual Builder.
6. Cliquez sur Créer.
7. Cliquez sur Configurer .
8. Cliquez sur l'onglet Git.
9. Dans la liste Ajouter 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 mine le code source de l'application avant d'exécuter le build. Si vous ne souhaitez pas réduire les fichiers source, désélectionnez la case Optimiser l'extension.

    La minification est un processus permettant 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 bande passante et le stockage du transfert de fichiers.

    Remarque
    
    Lorsque vous désélectionnez la case Optimiser l'extension, cet avertissement s'affiche : Optimisation non sélectionnée. Un package sans optimisation peut causer des problèmes de performances. Ainsi, évitez de le faire, sauf si vous effectuez un débogage ou un dépannage.
14. (Facultatif) Si vous voulez modifier le nom du fichier d'artefact, dans Créer un artefact, entrez le nouveau nom. 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 package de développement pour écraser 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 entré une valeur dans le champ Répertoire cible dans Copier les artefacts pour le travail de déploiement, elle est considérée 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. Si vous souhaitez supprimer les anciens artefacts du build, cliquez sur Paramètres . Dans l'onglet Général, cochez la case Ignorer les anciens builds et indiquez les options d'annulation.
20. Cliquez sur Enregistrer.

Le travail de déploiement déploie l'artefact de l'extension qui a été 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 Constructions .
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 Valeur par défaut du système OL7 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 d'un 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 (par défaut)
    • Dernier build conservé définitivement
    • 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 paramètre de permalien, de paramétrage ou de paramétrage à 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 le 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 build. Lorsque l'option Utiliser OAuth est sélectionnée par défaut, le message Authorization is required apparaît. Il indique que cette étape de build a besoin d'une autorisation unique pour gérer les demandes OAuth adressées à 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 les saisir lorsque vous y êtes invité.

    Dans les deux 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 vous 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
    
    Le type d'autorisation recommandé est OAuth. 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 l'authentification de base, puis entrez les informations d'identification d'un utilisateur pouvant 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 au cours de 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é lors de 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 le nom 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'ont pas accès peuvent voir le travail de build sur la page Aperçu 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 global 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 Constructions.
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 des règles par, situé au-dessus de la liste des travaux/règles, sélectionnez l'un des boutons radio suivants :
   • Sélectionnez Nom du job pour choisir un job 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 Travail de filtrage pour localiser rapidement le travail auquel ajouter les paramètres restreints.

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

     La boîte de dialogue Protection des travaux est affichée.

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

     Lorsqu'un travail n'est pas directement protégé mais est protégé par une règle à la place, un message d'information tel que le suivant affiche les règles, <ExampleRegex05> dans ce cas, 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 indiquer une chaîne qui correspond au nom du travail.

     C'est ce que vous verriez 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 le 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.

     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 global (test*) et nous sommes sur le point d'appuyer sur Créer pour créer une règle de protection de travail.

5. Cochez la case PRIVÉ.
   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
   

   Une fois cette option sélectionnée, seuls les utilisateurs et les groupes autorisés pourront afficher la page Détails de travail, modifier ou exécuter manuellement le travail. Si le travail est déclenché dans un pipeline par un utilisateur ou un groupe non autorisé, ou par SCM ou un minuteur, 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 parmi lesquels vous pouvez effectuer votre sélection.

   Sous Utilisateurs, vous pouvez voir une liste aplatie de tous les utilisateurs qui sont membres du ou des groupes, ainsi que 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 Utilisateurs, avec 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 autorisée-groups-and-users.png
   

   Voici ce que vous voyez pour le travail myProtectedJob après avoir sélectionné Alex Admin en tant qu'utilisateur autorisé.

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

   Voici ce que vous voyez 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 permettre aux membres du projet de 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 les membres du projet, et pas seulement les utilisateurs autorisés, à démarrer manuellement 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 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 de le griser. Avec ce paramètre, seuls les utilisateurs et les 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 déclencheurs ou les validations SCM démarreront et exécuteront 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 simplement la case Autoriser les validations et les déclencheurs à démarrer ce travail privé si vous voulez que les validations et les déclencheurs SCM puissent exécuter automatiquement ce travail.

     
     
     Description de l'illustration job-protection-private-allow-commits-and-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 les déclencheurs périodiques et les validations SCM le seront.

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

     Remarque
     
     

     Best Practice :

     Si vous utilisez la case à cocher pour permettre au build protégé d'être déclenché 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 un commit pour le déclencher.

     C'est ce que vous verrez 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'illustration job-protection-page-allow-commits-and-triggers.png
     

8. Cliquez sur Enregistrer.

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