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 a Job's Privacy Setting 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, 23D in your Test environment, then want to deploy the extension to your 23C Prod environment, you'll have to wait until your Prod instance has been upgraded to 23D before you can deploy successfully. In most cases, there shouldn't be more than a two week gap between pod upgrades.
Configure a Job's Privacy Setting
The project owner can mark a job as private to restrict who can see or edit a job's configuration, or run its build:
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 Project Administration tile's Builds page's Job Protection tab, 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 the Builds page's Pipelines tab.
An unauthorized user can't run a private build job manually, or through a pipeline, or via an SCM/periodic trigger.