Create and Configure Production Build Jobs
You need to set up some packaging and deployment jobs before you can deploy extensions to your Oracle Cloud Application's PROD instance. Follow this process:
- Migrate the configurations to the production Oracle Cloud Application instance. See Overview of Configuration Life Cycle and Overview of Migration in Configuring and Extending Applications for instructions.
- Create a build job that packages the extension. See Create the Production Packaging Build Job for instructions.
- Create a build job that deploys the extension to the production instance. See Create the Production Deployment Build Job for instructions.
- (Optional) Restrict who can see or edit the production build jobs or run their builds. See Configure Job Protection Settings for instructions.
- Configure the pipelines to run the packaging and deployment jobs in succession. See Create and Configure the Production Pipeline for instructions.
- Run the production pipeline to package the extension and deploy it to the production instance. See Run Production Pipelines for instructions.
Before You Configure Build Jobs and Pipelines
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.
Create the Production Packaging Build Job
The packaging job generates an extension artifact that's ready to deploy to the mainline.
Create the Production Deployment Build Job
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.
If you develop an extension on, say, 24D in your Test environment, then want to deploy the extension to your 24C Prod environment, you'll have to wait until your Prod instance has been upgraded to 24D before you can deploy successfully. In most cases, there shouldn't be more than a two week gap between pod upgrades.
Configure Job Protection Settings
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.
- A protection rule defined with a glob pattern will not overrule a job protection defined by using a name (no glob pattern or rule).
- A protection that is applied to a single job will override a protection applied by using a rule (defined by a glob pattern).
- When two rules are combined, the protection is determined by the most restrictive rule. You need to look at the events in the Activities feed and examine the notifications, which provide the information explaining the restrictions when one rule overrides another.
- A job will not be created if the user that is creating the job wouldn't be able to access their own job. The same principle is true for renaming jobs.
You can see if a job is private from several places in the VB Studio user interface. A private job is indicated by a Lock icon:
-
In the jobs list found on the Job Protection tab on the Project Administration page's Builds tile, to the right of each protected job's name.
-
In the Private column on the Builds page's Jobs tab.
-
In the jobs shown in the Pipelines tab on the Builds page.
An unauthorized user can't run a private build job manually, through a pipeline, or by using an SCM/periodic trigger.