Learn About Migrating to Oracle Cloud Infrastructure

Why Migrate to Oracle Cloud Infrastructure

Oracle encourages you to migrate your existing cloud resources to Oracle Cloud Infrastructure regions. You can gain several advantages by doing so.

In Oracle Cloud, you provision resources in specific regions, which are localized to geographic locations. Certain regions support the Oracle Cloud Infrastructure platform.

Oracle Cloud Infrastructure is Oracle's modern cloud platform that's based on the latest cloud technologies and standards. It provides more consistent performance and better features at lower costs. Oracle continues to invest in Oracle Cloud Infrastructure, including the addition of new regions, services, and features. See Data Regions for Platform and Infrastructure Services.

You can benefit from these additional administrative features when you migrate your cloud resources to Oracle Cloud Infrastructure:

Organize cloud resources into a hierarchy of logical compartments.
Create fine-grained access policies for each compartment.

About the Migration Scope

In this documentation, DevCS on Traditional is referred as the source DevCS instance and DevCS on OCI is referred as the target DevCS instance.

Before you migrate your source DevCS instance from Traditional to OCI, ensure that the target DevCS instance meets the prerequisites for the migration.

You need a DevCS instance in the OCI region set up with a dedicated OCI compartment and a bucket. This guide includes procedures that describe how to create the target DevCS instance, and how to set up a compartment and a bucket, but doesn't include detailed procedures on the configuration of basic OCI security, network, and storage resources that might be required to support your instance. Instead, this guide provides references to the OCI documentation, as appropriate.

Using the Export/Import Data feature of a project, you can automate the migration of some of the project's artifacts of the source DevCS instance to the project of the target DevCS instance. The artifacts that aren't migrated must be manually re-created in the target DevCS instance project.

This guide includes detailed procedures that explain how to export and import projects as well as migrate artifacts. This guide doesn't describe the new features available in the target DevCS instance. To find more about DevCS on OCI and its new features, see What is Oracle Developer Cloud Service? in Using Oracle Developer Cloud Service. To learn about OCI key concepts and terminology, see Key Concepts and Terminology in the Oracle Cloud Infrastructure documentation.

Compare Oracle Cloud Infrastructure to Traditional

Oracle Cloud services run in an Oracle Cloud account and use Oracle Identity Cloud Service, Oracle Identity and Access Management, or their own identity management systems to manage users and control access to cloud services.

For more information about both types of accounts, see About Oracle Cloud Accounts in Getting Started with Oracle Cloud.

Traditional Cloud Accounts do not use the Oracle Identity Cloud Service but use the traditional Identity and Access Management software to manage users and roles. When you migrate to OCI, you must migrate your users from Oracle Identity and Access Management to Oracle Identity Cloud Service. See Migrating from Traditional Cloud Accounts to Cloud Accounts with Identity Cloud Service in Administering Oracle Identity Cloud Service.

There aren't many differences between DevCS on Traditional and DevCS on OCI. DevCS on OCI employs a new build system that run builds on your OCI Compute VMs, and then stores the build and Maven artifacts on your OCI Object Storage buckets. To use DevCS on OCI, you must configure DevCS to use OCI compartments and buckets.

About the Build System in DevCS on OCI

In DevCS, you run builds of jobs on a Virtual Machine (VM), called a Build VM. In DevCS on Traditional, you run builds in an internal shared pool of Build VMs, which are owned by Oracle and are also shared between DevCS customers. You don't control the software installed on the Build VMs, not its Operating System (OS). The internal shared Build VMs run on Oracle Linux 6. The build artifacts and Maven artifacts are stored on the internal storage space of DevCS.

Builds in DevCS on OCI run on OCI Compute VMs that you own and don't share with other DevCS customers. The builds run faster compared to builds running in the internal shared pool and are more secure. You can also choose the platform of the Build VM and the software installed on it. The build and Maven artifacts are stored in your OCI Object Storage buckets.

This table summarizes the difference between the build system of DevCS on Traditional and DevCS on OCI.

DevCS on Traditional	DevCS on OCI
Builds run in an internal pool of VMs	Builds run on OCI Compute VMs
Oracle owns the Build VMs	You own the Build VMs
Build VMs are shared between DevCS customers	Build VMs are not shared between DevCS customers
The number of Build VMs are limited	You define the number of Build VMs as per your usage
You can't choose the region and shape of VMs	You can choose the region and shape of VMs
Build VMs run on Oracle Linux 6	You can choose to run Build VMs on Oracle Linux 6 or Oracle Linux 7
No control over software available on Build VMs	You can choose the software available on Build VMs
Build artifacts are stored in the internal storage space of DevCS	Build artifacts are stored in OCI Object Storage buckets

A Build VM Template defines the operating system and the software installed on Build VMs. After creating the templates, you allocate some Build VMs to each Build VM Template. When your organization's members create jobs, they associate a Build VM template with a job. When a build of the job runs, it runs on Build VMs allocated to the job's Build VM Template.

One Build VM runs one build at a time. When you allocate Build VMs to a Build VM Template, set the number of VMs to the number of jobs that you expect to run in parallel using that template. For example, let's assume you have 10 jobs (say Job 1, Job 2, through Job 10) that use the same Build VM Template with only one Build VM allocated to it. If all jobs run their builds at the same time, only one job's build runs (say Job 1) and other nine (Job 2 through Job 10) wait until the build of the job is complete. If each build takes two minutes to complete, Job 10 has to wait for 18 minutes before its build starts.

If you increase the number of Build VMs allocated to the Build VM Template to five, the wait time of jobs reduces. Assuming builds of Job 1 through Job 10 run at the same time, Job 1 to Job 5 run immediately on the five Build VMs and Job 6 to Job 10 wait until a Build VM is available. If each build runs for two minutes, then their wait time is two minutes. If you allocate 10 Build VMs, then there is no waiting time. All builds run immediately.

Note that the more VMs you have running at a specific time, the higher the cost. So, allocate the number of Build VMs to the Build VM Templates to match your usage. You can always add or remove VMs, based on your actual usage.

These steps describe what happens when a build of a job runs in DevCS on OCI:

The build executor checks the Build VM template of the job and then searches for a Build VM that's allocated to the template.
- If an allocated Build VM is available, the build executor immediately runs the build on it.
- If all Build VMs allocated to the Build VM template are busy running builds of other jobs using the same Build VM template, the build executor waits until a Build VM becomes available and then runs the current job's build on it.
- If no Build VM is allocated, the build fails.
The Build VM installs the software defined in the Build VM Template if any of these events happen.
- A build runs on a Build VM for the first time
- A Build VM wakes up after its sleep timeout period
- The software of a Build VM template is updated
Note that software installation takes some time.
After installing the software, the build executor clones the job’s Git repositories (if configured) to the Build VM, sets up the environment, runs the job's defined build steps, creates artifacts (if configured), and performs post-build steps (if configured).
After a build is complete, the build executor copies the artifacts (if generated) to the OCI Object Storage bucket.
The Build VM waits for some time for any queued builds. If no builds run in the wait time period, the Build VM uninstalls its software and stops.

To learn more about the software you can install on Build VMs and the new build system in DevCS on OCI, see Software Installed on the Build Executor and Configure and Run Project Jobs and Builds in Using Oracle Developer Cloud Service.

About the Migration Task Flow

At a high level, the migration process is composed of these tasks:

Task	Time Required	More Information
Create the target DevCS instance	30 minutes	Create the Target DevCS Instance in the OCI Region
Set up the OCI connections in the target DevCS instance	15 minutes	Set Up the OCI Connections on the Target Oracle Cloud Account
Set up OCI Object Storage bucket	10 minutes	Set Up an OCI Object Storage Bucket
Export a project's data in the source DevCS instance to an OCI bucket	15 minutes	Export Project Data From the Source DevCS Instance
Create a project with exported project's data in the target DevCS instance.	10 minutes	Create a Project With an Exported Project's Data in the Target DevCS Instance
Migrate the artifacts that weren't exported from the source DevCS project to the target DevCS project.	1.5 - 2 hours for all artifacts of a project	Migrate Other Artifacts and Data
Clean up the source DevCS instance	20 minutes	Clean Up Resources in Traditional