Here are some things you need to know before you configure and run build jobs and pipelines:

• Make sure that the source and target instances are of the same release, with the same standard and one-off patches applied to both environments.
• In the development packaging job, if you changed the default artifact's file name, get the new name and its path.
• If you configured the development packaging job to overwrite the application's version defined in visual-application.json, get the new version. You'll configure the production's packaging job to use the same version.

The packaging job generates an extension artifact that's ready to deploy to the mainline.

1. In the left navigator, click Builds .
2. In the Jobs tab, click + Create Job.
3. In the New Job dialog box, in Name, enter a unique name.
4. In Description, enter the job's description.
5. In Template, select the System Default OL7 for Visual Builder template.
6. Click Create.
7. Click Configure .
8. Click the Git tab.
9. From the Add Git list, select Git.
10. In Repository, select the Git repository. In Branch or Tag, select the production branch.
11. Click the Steps tab.
12. From Add Step, select Application Extension, and then select Package.
13. By default, the packaging step minifies the application's source code before running the build. If you don't want to minify the source files, deselect the Optimize extension check box.

    Minification is a process to remove the unnecessary characters (such as blank spaces, new lines, and comments) from the source code and reduce the size of the files, making the transfer of files consume less bandwidth and storage.

    Note
    
    When you deselect the Optimize extension check box, this warning is displayed: Optimization not selected. Packaging without optimization can cause performance problems, so avoid doing so unless you're debugging or troubleshooting.
14. (Optional) If you want to change the artifact file's name, in Artifact, enter the new name. By default, it is extension.vx.
15. (Optional) If you configured the development packaging job to overwrite the extension's default version defined in the visual-application.json file, specify the same version in Extension Version.
16. Click the After Build tab in the Job Configuration window.
17. From Add After Build Action, select Artifact Archiver.
18. In Files to archive, enter the build artifact name.

    You can use wild characters. For example, *.vx. Make sure that you include the path for the Application Extension build artifact.

    If you entered a value in the Target Directory field in Copy Artifacts for the deployment job, it is considered to be a subdirectory of the workspace and should be part of the artifact's path in the Build Artifact field.

19. If you want to discard the build's old artifacts, click Settings . In the General tab, select the Discard Old Builds check box and specify the discard options.
20. Click Save.

The deployment job deploys the extension's artifact that was generated in the packaging job to the Oracle Cloud Application's production instance. Before you create the job, make sure you have credentials that VB Studio can use to access the Oracle Cloud Application's PROD instance.

1. In the left navigator, click Builds .
2. In the Jobs tab, click + Create Job.
3. In the New Job dialog box, in Name, enter a unique name.
4. In Description, enter the job's description.
5. In Template, select the System Default OL7 for Visual Builder template.
6. Click Create.
7. Click Configure .
8. Click the Before Build tab.
9. From Add Before Build Action, select Copy Artifacts.
10. In From Job, select the packaging job that generated the extension's artifact.
11. In Which Build, select one of the following:
    • Last successful build (default)
    • Last keep forever build
    • Upstream build in this pipeline instance
    • Specified by permalink
    • Specific build
    • Specified by build parameter

    Depending on what you select, you may be prompted to select which permalink, build, or build parameter you want to be used.
12. Leave other fields with their default or empty values.
13. Click the Steps tab.
14. From Add Step, select Oracle Deployment.

    This image shows the Oracle Deployment build job page that's been partially filled in.
    
    
    

15. In Target Instance, select the environment with the Oracle Cloud Application's production instance.
16. In the Authorization section, select Use OAuth or Use Basic to specify the type of authorization used to run this build step.

    • If you selected Use OAuth, the Authorization is required message indicates that this build step needs to be authorized. Click Authorize and enter credentials to access your environment's Oracle Cloud Applications instance; you can also run the job manually and enter the credentials when prompted. Either way, it is recommended that you authorize your OAuth connection during initial configuration. If you skip this step, developers won't be able to publish their changes from the Designer and will need to complete the required authorization before attempting to deploy changes again.

      Once authorized, the Authorization has been provided message shows. If the OAuth token used to authorize the connection expires during extended periods of inactivity (say, when you're away on vacation), you can click Renew Authorization to renew the token (or you can run the job manually, so you're prompted to authorize any expired OAuth tokens).

    • If you selected Use Basic, in Username and Password, enter the credentials of an IDCS user who is not only an Oracle Cloud Applications user, but one who can connect and deploy from the Oracle Cloud Application's production instance. These credentials must be those of a local user, not a federated identity, and must not require multi-factor authentication.
17. If you changed the archive artifact files default file names in the production packaging job, in File names, select Use custom file names.

    In Sources and Build Artifact, enter the same file names (with the path) that you specified in the packaging job.

18. Click Save.

To restrict access, the project owner can mark a job as private. Users that don't have access can see the build job in the Jobs Overview page, but they can't see the Job Details page or view the build's details; nor can they see or edit the job configuration, or delete/enable/disable the build job. In addition, the project owner can use a glob pattern that is defined in a rule to protect any job whose name matches the specified pattern.

1. In the left navigator, click Project Administration .
2. Select the Builds tile.
3. Select the Job Protection tab.

   The Job Protection page is displayed.

   
   
   
   

4. In the Find rules by panel, located above the jobs/rules list, select one of these radio buttons:
   • Select Job name to choose a job from the list.

     If your project has many jobs, you may have difficulty finding the specific job you want to protect. Use the Filter job bar to quickly locate the job to which you want to add the restricted settings.

     If a job in the list of jobs to the left has a lock icon next to it, it has already been protected. A protected job's restrictions can still be modified, removed, or the list of authorized users and groups can still be changed.

     The Job Protection dialog box is displayed.

     
     
     
     

     When a job is not directly protected but is protected by a rule instead, an informational message like the following one will show the rules, <ExampleRegex05> in this case, that protect the specific job:

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

   • Select Glob pattern to specify a string that is matched against the job name.

     This is what you'd see if no rules have been defined yet.

     
     
     
     

     The glob syntax can be used to specify pattern-matching behavior. These wildcard characters can be used in glob patterns: *, **, ?, [], {}, and \.

     Either select an existing protection rule from the list or click + Rule to display the New Protection Rule dialog and create a new one.

     The Protection Rule dialog box is displayed.
     
     
     Here we've entered a name (Test Rule) and a glob pattern (test*) and we're about to press Create to create a new job protection rule.

5. Select the PRIVATE check box.
   This is what you see after selecting the Private option for a job.

   
   
   
   

   With just this option selected, only authorized users and groups will be able to view the Job Details page, edit the job, or manually run it. If the job is triggered in a pipeline by an unauthorized user or group, or if it is triggered by SCM or a timer, it will not be initiated.

   This is what you see after selecting the Private option for a protection rule.

   
   
   
   

6. Click in the Authorized Users/Groups field to display a dialog that lists the project's Groups and Users you can select from.

   Under Users, you can see a flattened list of all users that are members of the group(s) as well as ones that were added individually. For example, the dev-group members (Clara Coder, Don Developer, and Tina Testsuite) appear in the Users list, along with Alex Admin, who was added individually. From the list, select one or more groups and/or users. Don't forget to add yourself.

   
   
   
   

   This is what you would see for the myProtectedJob job after selecting Alex Admin as an authorized user.

   
   
   
   

   This is what you'd see for the Test Rule protection rule after selecting Alex Admin as an authorized user.

   
   
   
   

7. Select the checkboxes to allow project members to manually start private jobs and/or allow commits and triggers to automatically start private jobs:

   • Select the Allow any member of the project to manually start this private job checkbox to allow any project member, not just authorized users, to manually start the job.

     This what you'd see after selecting the Allow any member of the project to manually start this private job check box for the myProtectedJob job.

     
     
     
     

     Notice that when you select the first checkbox, VB Studio automatically selects the second checkbox, which allows commits and triggers to start the private job, and grays it out. With this setting, only authorized users and groups can view the Job Details page or edit the job, but any project member can start and run the job. In addition, SCM commits or triggers will also automatically start and run the job.

     This what you'd see after selecting the Allow any member of the project to manually start this private job check box for the Test Rule protection rule.

     
     
     
     

   • Select just the Allow commits and triggers to start this private job checkbox if you want SCM commits and triggers to be able to automatically run this job.

     
     
     
     

     With just this checkbox selected, periodic triggers will run any job or pipeline, including private jobs set to allow commits and triggers to start the private job. However, if a pipeline includes a private job with this option selected and a non-authorized user attempts to run the pipeline manually, the private job won't run but periodic triggers and SCM commits will.

     Leave the checkbox unselected if you don't want the job to be started when it is triggered by an SCM commit or timer.

     Note
     
     

     Best Practice:

     If you use the checkbox to enable the protected build to be triggered by an SCM commit, you need to protect the branch that the build job is tied to. If you don't do this, anyone can trigger the protected build by making a commit to trigger it.

     This is what you would see if you selected the Allow commits and triggers to start any job matching this glob pattern for the Test Rule.

     
     
     
     

8. Click Save.

   The activity stream displays all changes to a job's protection status, like changing the job protection from public to private, or private to public, or changing a private job to allow commits and triggers.