CI/CD Pipeline Setup for Oracle Content Management

The objective of this document is to describe set up of continuous integration / continuous deployment (CI/CD) pipeline to manage content model, layouts, source code and automate deployment from DEV > TEST > PROD Oracle Content Management (OCM) instance, while ensuring released code is bug-free and does not break rendering / functionality of existing front ends in PROD. It is assumed that customer has a Source Control Management (SCM e.g., Git or BitBucket) and Automation server (AMS e.g., Jenkins or GitLab) in place.

CI/CD Pipeline Suggested Flow

• DEV instance will be a work-in-progress environment. Developers may be deploying code to it at random for unit testing, so that the DEV instance may break and should therefore, have a scheduled redeploy from the DEV branch in SCM via an AMS job to restore it to last functional version of DEV.
• Most of the operations to / between OCM instances will be performed through the CLI command available in the OCM Content Toolkit. The toolkit is used both locally by developers and by AMS jobs for automated deployment.
• Initial version of the theme, components, content layouts or content types will be downloaded locally into /cec-src folder using relevant CLI command in the OCM Content Toolkit, then committed as the master / main branch in SCM. You should set .gitignore to ignore servers, content, templates subfolders.
• The SCM repository will have multiple branches – one for DEV, one for TEST, and one for PROD instance. Whenever a feature needs to be created, a feature branch will be created from the DEV branch for each unit of work (e.g., theme change, component customization, content type change, etc.). Developers clone this feature branches locally and work on the code changes. Once done, they deploy new code manually via CLI command in the OCM Content Toolkit to the DEV instance. DEV instance may become unstable and thus, need regular redeploy from the stable DEV branch of latest working code.
• Typically, asset types are also downloaded (via cec download-type) from OCM instance and checked into your SCM repository, so any changes to asset types in DEV instance can be replicated to TEST instance automatically when the DEV branch is merged to TEST and a deploy is triggered manually or by an AMS job.
• Once work on new feature release is completed and tested on your DEV instance, the feature branch in SCM is merged into the DEV branch. Updated branch becomes the stable codebase of all your code. Typically, at the end of the week, scheduled AMS job redeploys the DEV branch from SCM to the OCM DEV instance. That ensures that only the latest DEV committed code is available in DEV instance.
  • NOTE: Manually deployed code to DEV that is still WIP and not yet committed to the DEV branch in SCM repository will be overwritten by this redeploy job.
• Once the DEV code branch is ready to be deployed to the OCM TEST instance, it is merged to the TEST code branch in SCM repository. The AMS can listen via webhooks on commits to TEST code branch and trigger a build job to do the following:
  • Stand up a Docker image which installs the latest OCM Content Toolkit inside OCI OKE or VM Docker engine. That helps to ensure that you are always using the lates version of the Toolkit. 
  • Install SCM client inside and clones the TEST branch into the /cec-src folder of the OCM Content Toolkit installed in the Docker container.
  • Run a shell script that performs the following actions:
    • Upload all components, content layouts or content forms and publish them (e.g., cec upload-component & cec control-component).
      •  NOTE: Latest versions of the Toolkit have a -p flag in the cec upload-component command to automatically publish the component in the same operation.
    • Share all components with relevant user groups (to ensure components visibility) (e.g., cec share-component).
    • Upload asset types to replicate type updates (e.g., cec upload-type).
      • NOTE: When you upload asset types, the order is important. You may consider implementing a process that reads the types and sorts your types so that referenced types are always updated before the referencing type. That might present a problem if you have circular dependencies in your content model which you can resolve via manually created list of your type update order.
    • Share all asset types with relevant user groups (e.g., cec share-type).
    • Optionally, add asset types to a repository (e.g., cec control-repository add-type).
    • Upload theme to file system (e.g., cec upload-folder ~/Downloads/docs -f theme:blog1Theme –server MyServer);
    • Publish theme (e.g., cec control-theme publish -t Theme1);
  • IMPORTANT: All servers in the CI-CD the pipeline (AMS, SCM, OCM Content Toolkit, OCM instances) need to be able to communicate across the network.
• The OCM TEST instance is where you perform functional, integration and accessibility testing. Therefore, it needs to merge the latest codebase from the DEV branch in SCM with the latest content from OCM PROD instance. Code deploys from SCM can be automated via an AMS job. The same job can be used to import content from OCM. Alternatively, you can use Asset Sync server in the OCM Content Toolkit to sync content in real-time from PROD to TEST or manually replicate content via the CLI commands.
  • NOTE: The Asset Sync server is design to sync asset changes, not for asset replication in bulk.
• Similar process is used for TEST to PROD instance deployments – once code on TEST branch in SCM is approved for rollout, the TEST code branch is merged into PROD. On code commit to PROD branch, a AMS job is triggered with the same steps as described above (create Docker image > clone PROD code branch > run script with the deploy target PROD).
  • NOTE: We recommended to keep the PROD deployment as a manual process to make sure you have full control on when the code is deployed. Clicking ‘build now’ manually to start PROD deployment helps to prevent committing something to PROD and triggering an automatic deploy by mistake.
• DEV, TEST & PROD code branches in the SCM repository continue to exist and maintain separate versioning even after the merges, so that the deployment cycle can start again from DEV with new feature branches.

The above diagram illustrates the CI/CD Pipeline setup for OCM

NOTE: We recommend using a Docker Image, instead of permanent OCI Compute VM as in the container the latest version of the OCM Content Toolkit will be automatically installed when AMS job runs. Since the OCM Toolkit is updated on a bi-weekly basis, having an install on an OCI Compute VM will lead to the OCM Toolkit becoming quickly outdated, therefore you will miss on the latest features / fixes.