NOTE: This blog post is one in a series of blogs covering various sub-topics within the "Extending Oracle Fusion SaaS with OCI" topic area. For an introduction to this topic and a listing of other articles in the series, refer to "Extending Oracle Fusion SaaS with OCI - Introduction"
Developing software, and getting it deployed to enterprise systems, can be a real challenge. First and foremost is the need to have checks and validations in place to ensure that what is being developed will address users' business requirements in the most optimal manner. After design and development, formally defined alpha and beta testing cycles have to be in place. This is where issues and bugs are raised and resolved before systems go live. After bug fixes comes unit and system testing, and likely new bugs will be identified and will need to be resolved. After clean runs of all QA tests, the software can be packaged and deployed to production.
Updates to existing systems present challenges similar to new development, but with system updates there are additional issues: backwards compatibility, and addressing the potential for any instabilities or regressions to existing features that may be introduced as part of an upgrade cycle.
In the past, to address the challenges involved with new software development and updates to existing systems, enterprise IT departments tended to minimize the number of upgrade events, in some cases scheduling new software releases for once a year or even less frequently. For users, obviously this was a totally unsatisfactory and insufficient resolution on several levels. First, the needs of the organization were addressed poorly with yearly systems upgrades (which probably had a lot to do with establishing IT's reputation in the past as being unresponsive to the organization). Second, the sheer magnitude of annual releases brought its own issues: sorting out complex interdependencies, tracing root causes of problems, devising effective testing strategies, and the like.
More recently, IT departments have by and large determined that it may be better for them and better for their users to shorten development/deployment cycles, which tends to reduce the number of changes included in upgrades but decreases the possibility of being blindsided by a bunch of stability, logic, and/or performance issues. With these process changes, new development methodologies (e.g. Agile and related schools) replaced the older waterfall approaches, and new automated toolkits and methodologies were born and evolved to better manage the quicker pace of software release cycles. Thus, Continuous Integration/Continuous Deployment (CI/CD) was born.
There are numerous advantages to following CI/CD processes and using various automated tools to support these processes:
- Release cycles are shorter and users are generally happier and more productive, as they get new features more quickly
- The process of deploying smaller code deltas is easier to manage and there is far less potential for unwanted side-effects.
- If there are issues with a deployment, it is easier to identify, isolate, and either correct problems or temporarily rollback the release.
- Due to smaller footprints, updates are less prone to cause major disruptions.
- Quality assurance and testing scenarios are easier to build and manage, and testing tends to be more thorough given the reduced number of flows to test.
Incorporating CI/CD methodologies to support Oracle SaaS extension development, including SaaS extensions that incorporate OCI platform product offerings, is not only possible today, but recommended to increase development team productivity and improve overall quality of the delivered extensions. Currently Oracle offers a number of packaged alternatives and ad-hoc approaches to support CI/CD.
In the context of the entire history of computer software development, CI/CD is a relatively recent phenomenon. Tools supporting various CI/CD processes and some manner of automated scripting have been around for the past 10 or 15 years – Hudson and Jenkins come to mind here – and toolkits have continued to evolve as CI and CD have broadened their scopes. The core architectural concept in CI/CD is the "pipeline" – which can be thought of as a defined set of logically-related steps that start with moving code from a developer branch to a main branch in a code versioning system (after local unit testing and validation of course), and ends with those code updates, along with other developers' contributions included in the main branch, getting deployed to test systems. After deployment and testing, the update package can then be deployed to production systems.
In the Oracle Public Cloud, a platform for creating and managing deployment pipelines was included in the Oracle Developer Cloud Service product (circa 2018). A couple of years later Visual Builder Studio was built on top of the foundations of Developer Cloud Service. Visual Builder Studio is the recommended platform for building the new generation of Fusion SaaS extensions that incorporate Orade Redwood-themed user interface objects built with Visual Builder.
Visual Builder Studio, CI/CD and SaaS Extensions
Visual Builder Studio includes everything that was supported in Developer Cloud Service, along with tightly-coupled Oracle Visual Builder design time and runtime environments. For SaaS extension projects, VB Studio supports two methods for extending Fusion SaaS applications. First, for pages that have been built to support it – i.e. the ever-expanding set of Redwood-themed flows and pages -- it is possible to create a development project for configuring page behaviors and page appearances. Second, it is also possible to create standalone Visual Builder pages that can be integrated with Fusion SaaS applications. Both methods are managed with a robust continuous integration and continuous deployment toolset.
Typically, a Visual Builder admin will create a VBS project to support development work by a group of people responsible for a development project. A VBS project is the container that organizes the people, tools, and processes dedicated to the work project. Included optionally within a VBS project are git repositories, build jobs, and deployment definitions. (There are also several powerful project management features included in Visual Builder Studio, but they are not directly related to the CI/CD discussion here.) Within a project, each developer usually gets a workspace, which acts as a dedicated standalone development environment for one individual. VB Studio automates the process of merging individual developers’ work into a project-level master git repository, from which the pipeline tools draw to build applications using a number of automated processes that are packaged with the framework.
One or more build pipelines are created in the project to manage the build processes. These pipelines control source code location, where to run the build jobs, how to run the build jobs, and where to write the build outputs or artifacts so that they can be deployed to dev, test, and/or production targets. Full logging and reporting capabilities are included in build pipeline definitions.
Once build pipeline jobs successfully create packaged artifacts, a set of deploy pipeline jobs takes over to deploy packages to runtime environments of different types. For these deployment pipeline jobs, the logging and reporting capabilities are virtually identical to build pipeline jobs.
With Fusion SaaS application extensions, Visual Builder Studio supports creating projects from a predefined set of templates. The Application Extension template will create a project that includes git repositories, a development environment definition that points to where the SaaS application is running, an automatically-generated build pipeline, and if so desired, a private workspace definition to host a developer’s app extension edits and modifications. Deployment pipeline jobs to production environments will still need to be created manually.
In Visual Builder build and deploy pipelines, it is also possible to target non-Fusion SaaS platforms. At the time of this document's publication, work is underway to make calls to OCI DevOps pipeline management API’s, which will make it possible to support different OCI/SaaS integration architectures, incorporating, for example, Oracle Functions, Oracle Container Engine for Kubernetes, and compute instances into one managed CI/CD set of pipelines for a development/deployment project. These enhancements will allow for a wide variety of oci4saas integration options and architectures.
OCI DevOps: CI/CD Tooling to Support OCI Cloud-Native Development
OCI DevOps is Oracle Cloud Infrastructure's CI/CD service that is used to automate the build, delivery, and deployment of developed software to OCI platforms of various types. As is the case with other CI/CD frameworks, the goal is to make it easier for developers and devops resources to streamline development, build, and deploy processes with greater efficiency and less chance for error.
Similar to Visual Builder Studio, in OCI DevOps a project is the top-level container for organizing pipelines, build and target environments, artifacts, and pipelines into one centralized management area. Moreover, the core piece of the deployment process is the pipeline, which consists of a series of orchestrated steps (referred to as stages) run serially or in parallel to deploy dev project artifacts to runtime targets.
OCI DevOps is focusing exclusively on OCI compute deploy targets at this time. Targets include Oracle Functions, Container Engine for Kubernetes (OKE), and generic compute instances. Therefore, to fully support a SaaS development project, OCI DevOps will have to be integrated with Visual Builder Studio.
Due to the variety of platforms and tools that need to be supported in any CI/CD framework being used for developing and deploying Oracle SaaS extensions, there are several ways to utilize CI/CD methodologies in a SaaS extension development project. Visual Builder Studio includes support for managing integration and deployment pipelines for many Oracle SaaS and OCI cloud-native platforms. While its focus at the time of this writing is on supporting extensions built with Visual Builder, it is possible to include Oracle Functions targets in pipelines along with other OCI targets. Work is underway to allow a Visual Builder Studio pipeline to call pipeline definitions in the OCI DevOps product, which theoretically will allow inclusive, complete end-to-end support for automating multi-platform SaaS extension Continuous Integration and Continuous Delivery.