1. Learn about selecting an appropriate CI/CD architecture
  2. Identify the Most Suitable Architecture or Solution

Identify the Most Suitable Architecture or Solution

Consider the series of evaluation factors (or stressors) to identify the reference architecture (RA) or solution that best meets your needs. The following sections provide you with information about the factors you should consider.

For each factor, we provide you with an indication of whether an architecture or solution supports the factor or not. If necessary, you can make it more nuanced by giving each factor a numeric score. Use the information and decision matrix using these recommendations.

  • Keep track of which columns match your preferred answer.
  • Compare the RA or solution that best meets your needs against each evaluation factor using the decision matrix.
  • Add a weightage to the factors that are more important to you than others.

Consider the Various Evaluation Factors

Consider each evaluation factor and then compare them with each architecture and solution to determine the one that best suits your needs.

Container, Virtual Machine (VM), or Specialist

You can scale resources efficiently for processes that demand more compute power by deploying processes to containers within a container orchestration environment like Kubernetes. Tasks such as such as unit tests and static code analysis have the potential to benefit from this. The downside of using containers is the increased complexity in the end-to-end configuration. Your team will need to know how to use container orchestration tools such as Kubernetes. Using containers also ensures that when the containers are destroyed they prevent accidentally picking up transient dependencies or previous state data.

Using a VM is simpler as you can build a single VM to handle all the steps of a pipeline. A container is monolithic in nature. A VM approach also alleviates issues such as allowing developer hosting and avoids issues of using Windows versus Linux hosts.

Some specialist scenarios will only support PaaS or SaaS products where the build process prepares and deploys artifacts for the service. You can orchestrate this using a general purpose tool. In some cases using a tool specific to the requirement can be more beneficial. For example, Oracle Visual Builder Studio is designed for solutions involving Visual Builder.

Pipeline Orchestration with OCI Native with Open Source/Third-Party Products

Using domain specific or very customizable tools including open source tools such as Jenkins can offer greater freedom in the build process during execution when compared to using OCI Native solutions. Although tools like OCI DevOps release new features on a regular basis. But this flexibility comes at the cost of managing more process stages such as deployment, patching, and monitoring, even when executing typical pipelines.

Standardized Deployment Repositories or Special Product Repositories

Native services will support your requirements when you manage configurations using industry-standard services such as OCI Git, GitLab or GitHub, and similar tools. CI/CD processes may be constrained with partially integrated legacy repositories. You may need to make significant changes to the pipeline be able to use CI/CD processes with legacy repositories.

Industry-Standard Configuration Management or Legacy Tools

When using cloud-provided services, it is typical for the service to only support industry-standard solutions using Configuration Management (CM) systems such as Git and SVN. These service providers may also support any specialist configuration management mechanisms that the vendor's own products need. If you must use a legacy or niche CM system then it may become necessary to consider third-party solutions that the CM system provider supports. For example, support for CVS as a legacy solution may need users to use third-party tools to manage configuration.

Multicloud or Single Cloud Deployment

Deploying the same core solution to multiple clouds can add complexities that you should consider. For example, if the deployment process is incorporated into a Terraform service, then each cloud provider will need to have deployment processes that take into account the differences from various Terraform providers. More subtle considerations such as a target chipset for Docker images may be required as different images will need to be created.

To ensure better security, you can choose not to expose your deployment targets for an external deployment solution. For example, if you're deploying to Oracle Container Engine for Kubernetes (OKE) and Azure Kubernetes (AKE), you can use GitHub to hold the common code and GitHub Actions to orchestrate the container build. But, you can choose not to expose AKS and OKE directly to GitHub Actions. Instead, consider a multistage solution with Azure and OCI to provide deployment orchestration and use GitHub for the continuous build processes or the core code.

Consider a multistage solution when Infrastructure-as-Code (IaC) is a part of the deployment process. This allows each environment to have a different IaC configuration for provisioning compute, storage, and managed services. Using Kubernetes enables you to limit or remove such issues.

Process Customization or Bespoke Processes

If you need special or niche processes, the tools to support the build pipeline must allow extensions for custom configuration. Building your own bespoke processes requires more effort. You should take into consideration and assess the risk of how future changes may prevent the customization from working.

Scaling Potential

Development workloads can fluctuate due to factors such as common trends during a working day. For example, commits to wrap up end-of-day activities that trigger CI/CD processes result in an increase in workload at the end of the workday. As projects progress through their lifecycle of build, release, and deploy, build infrastructure sees an increase in demand. There is a pattern of an increase in requests for small changes as minor issues are addressed at the end of release/sprint cycles.

Review the Decision Matrix

The architectures and solutions are grouped under a common number, such as 1a, 1b, and 1c based on where they have subtle variations. For example, a single node for the CI/CD solution or the same solution with a different tooling configuration indicates that the solution can operate at a larger scale. Each grouping is a column header in the decision matrix and each factor is a row header. Callouts within the table, such as 1, provide additional information.

Architecture and Solution Groupings

  1. Jenkins Orchestration (with two variants)
    1. Set up a CI/CD pipeline for cloud deployments with Jenkins: minimal deployment approach with no scaling or resilience
    2. Deploy Jenkins in master/agent mode: scalable and resilient deployment
    3. Build a continuous integration and deployment pipeline using Oracle DevOps service
  2. GitLab
    1. Deploy GitLab to enable CI/CD pipelines on OCI
    2. Deploy GitLab Runners on Oracle Container Engine for Kubernetes with cluster autoscaling
  3. OCI DevOps: Variants for serverless and containers
    1. Build a CICD pipeline using Oracle Cloud Infrastructure DevOps service and OCI Functions
    2. Build a continuous integration and deployment pipeline using Oracle DevOps service
  4. GitHub Actions: Build a CI/CD pipeline for cloud deployments using GitHub Actions and Oracle Cloud Infrastructure DevOps service
  5. Modern App Strategy: Plan Modern App Deployment strategies with Oracle Cloud Infrastructure Devops
  6. Mobile Hub: Create a CI/CD pipeline for mobile apps
  7. Bots: Create a CI/CD pipeline for bots custom components

The following decision matrix represents the variations between the architectures and solutions to enable you to identify the appropriate one for your business needs.

Factor 1. Jenkins Orchestration 2. GitLab 3. OCI DevOps 4. GitHub Actions 5. Modern App Strategy 6. Mobile Hub 7. Bots
Container, virtual machine (VM), or specialist

VM and Container

(Although provided solution targets VMs)

 VM or Container VM & Container VM and Container VM and Container Specialist Specialist
Pipeline orchestration with OCI native or unmanaged with open source/third-party products Yes Yes No Yes No No (Oracle Dev Cloud) No
Standardized deployment repositories Yes1,3 Yes1 No No (in RA implementation - but possible) Yes1 No No
Configuration management repositories supported GIT, SVN and others GIT GIT GIT GIT GIT GIT
Multicloud or single cloud deployment Single2,3 Single or Multicloud Single2 Single or Multicloud Single2 Single No
Process customization or bespoke processes Yes Yes Yes Yes Yes No Limited
Scaling potential

1a – No

1b – Yes

 Yes Yes Yes Yes No No

Table Footnotes

Note:

  • 1 OCIR is standards compliant.
  • 2 Uses OCI to drive processes in other environments. But also raises the challenge of undesirable exposure to services in other environments.
  • 3 Uses OCI DevOps in the deploy phase for option 1a, so limits that phase to a single cloud.