One of our customers was still running a Developer Cloud Classic instance. We decided to migrate to Developer Cloud. Since the inception of Oracle Cloud and Oracle Platform as a service, services have moved from "Classic" to "Autonomous" to "Native". What does this mean and why does Oracle have all these different types of services in their cloud? And why would you care? Let's go back in time a little bit.
Still confused? Let's look at an example: Oracle Integration Cloud.
It has several advantages to move to Oracle Cloud Infrastructure native services:
Now that we know how Oracle moves her services, what is the situation for Oracle Developer? Oracle Developer Cloud Classic is provisioned in the classic infrastructure and as a result, uses Oracle Classic infrastructure components for load balancing, networking, storage, etc. There is no native Developer Cloud service (yet?). However, you can move your Developer Cloud Service Classic to OCI (in the dedicated ManagedCompartmentForPaaS compartment). Developer Cloud service offers different features: a GIT repository, build jobs, deployment jobs, wiki, issue system, to name a few. For a number of these features you need resources. From Developer Cloud Classic you can connect to OCI to use the resources. For example: a build job needs a build VM and storage to store the artifacts. So even though the Developer Cloud Service itself is not running in a compartment of your choice, the jobs you are running and the code you are storing is making use of these features. But Developer Cloud Service itself, also uses networking to give you as a developer access to the console. Think about the load balancer, an IP address etc. For this customer, we wanted to remove all resources from the Classic Infrastructure, we already migrated Mobile Cloud Service to Mobile Hub and API Platform Classic to API Platform. Developer Cloud Classic was the last man standing...
If you are not interested in my experience of the migration, but just want to go ahead and do it, you can find the Oracle documentation here.
We executed the following steps:
You can now create the organization properties, by copying them from the Developer Cloud Classic instance or create your project using new properties (which what we did).
If you are planning to create build jobs in the future (which we are planning for Kubernetes), you need to make a connection to OCI from Developer CS.
Now we have our Developer Cloud setup, it is time to migrate the stuff from the old instance.
To avoid mistakes and make sure we have consistent naming conventions, we use Terraform scripts to create resources. You can find the documentation here.
Note: you can skip all the optional fields mentioned, all you need is the compartment_id, the bucket_name and the bucket_namespace.
We will use a compartment we created for this purpose: DEVCS compartment, and the user, devcs.user with a public and private key, the group and the policies. For more information, see the documentation. Note that in the documentation, separate users and groups are setup for both managing the resources from Developer Cloud Service and reading and writing the data from the storage resource to manage the import and the export. In our case, it did not add much value to have separate users and policies, so we reused the devcs.user for this purpose. This means we din't add the policies because devcs.user can already manage all resources in the compartment.
How to do that is described here
So, what is the preferred method? After executing the steps above my recommendation is:
Happy coding 😀
A history lesson
Oracle started with a Cloud Infrastructure and Platform (PaaS) and Software services (SaaS) to catch up with competitors like Amazon (AWS) and Microsoft (Azure). Soon after realizing the first generation infrastructure an improvement project was started. This resulted in the current Oracle Cloud Infrastructure (OCI) with compartments, services that can be used by different PaaS services, improved networking etc. At the same time, the first generation of PaaS services was improved, to become "Autonomous": the customer does not have to worry about maintaining the platform, this is done by Oracle. This resulted in products like Oracle Autonomous Data Warehouse and Autonomous Oracle Integration Cloud. The name "Autonomous" was quickly dropped from most services except Database related products, but the advantage was clear: Oracle manages the platform instances, so customers don't have to worry or worry less about availability, upgrades and patches. A number of these services were not using the new features of the Oracle Cloud Infrastructure. Oracle released new platform services: so called "native" services that use the networking, compartment, notification and other features of OCI. Note that Autonomous Database products and services like Kubernetes Engine and Function were native from the start.Still confused? Let's look at an example: Oracle Integration Cloud.
Example: OIC
Integration (also known as Oracle Integration Cloud or OIC) started with Integration Classic. When you provisioned OIC Classic it was provisioned in the Oracle's first generation, or classic, infrastructure. The next generation, which was called Autonomous OIC for a while, is/was running in Oracle Cloud Infrastructure. However, it is not making use of all the native services or functionality that OCI offers: you can't define the compartment it is provisioned in, it does not use the notification services, it does not have Terraform support etc. It is running in the specifically dedicated ManagedCompartmentForPaaS compartment, that gets automatically created when you provision (non-native) Oracle Integration The latest (and hopefully last) installment is Oracle Integration, which is native. When you provision it, you must create a compartment for it first and it uses all the available services (networking, notification etc.) of Oracle Cloud Infrastructure.It has several advantages to move to Oracle Cloud Infrastructure native services:
- Organize cloud resources into a hierarchy of logical compartments.
- Create fine-grained access policies for each compartment.
- Support for Terraform for provisioning
- Usage of Security and network features in Oracle Cloud Infrastructure
- Last but not least, new features are being added to the native service, not to the non-native services.
Migration of Oracle Developer Cloud Classic
If you are not interested in my experience of the migration, but just want to go ahead and do it, you can find the Oracle documentation here.
We executed the following steps:
- Create the Developer Cloud instance in OCI
- Create the storage resource for migration of the project
- Migrate the project
- Add the users
- Remove the Developer Cloud Classic instance
Create the Developer Cloud instance in OCI
Because it is not native yet, you can't create the instance using Terraform. The easiest way is to use the user interface:- Login to OCI
- Select "Developer Cloud" from Platform Services
- Enter the name you want to use
- Add a description and some tags (optional)
- Confirm
You can now create the organization properties, by copying them from the Developer Cloud Classic instance or create your project using new properties (which what we did).
If you are planning to create build jobs in the future (which we are planning for Kubernetes), you need to make a connection to OCI from Developer CS.
Now we have our Developer Cloud setup, it is time to migrate the stuff from the old instance.
Create storage resource
The first thing to do when you want to export and import the git repository, is to setup an OCI Object Storage bucket to host the data from the exported project. You can use a common container for all projects, but we recommend keeping separate storage buckets per project.To avoid mistakes and make sure we have consistent naming conventions, we use Terraform scripts to create resources. You can find the documentation here.
Note: you can skip all the optional fields mentioned, all you need is the compartment_id, the bucket_name and the bucket_namespace.
We will use a compartment we created for this purpose: DEVCS compartment, and the user, devcs.user with a public and private key, the group and the policies. For more information, see the documentation. Note that in the documentation, separate users and groups are setup for both managing the resources from Developer Cloud Service and reading and writing the data from the storage resource to manage the import and the export. In our case, it did not add much value to have separate users and policies, so we reused the devcs.user for this purpose. This means we din't add the policies because devcs.user can already manage all resources in the compartment.
Move the git repository
We are now ready to move our git repository. We will migrate the entire project that the git repository is part of.- Export your project. You find extensive documentation here.
- Import the data into a new project. You find extensive documentation here.
- Create project
- Import project
- Add users (those are not migrated, unfortunately)
Alternative
Because in our case, we only had a git repository we wanted to migrate, the alternative would have been to skip the export/import step and simply create a new remote git repository in the new project of the new instance and then push the code to that remote.How to do that is described here
So, what is the preferred method? After executing the steps above my recommendation is:
- If you only have a git repository and no Wiki, Jira or build jobs you need to import just create a new project and a new remote git repository
- If you have build jobs, Wiki pages, Jira issues that you want to keep, use the import/export methodology described in this blog post.
Remove the Developer Cloud Classic instance
Now that we are done and have the new project up and running, we need to clean up the old instance. The documentation describes how to do that here.Happy coding 😀
