A history lessonOracle 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: OICIntegration (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 OCIBecause 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)
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 resourceThe 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 repositoryWe 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)
AlternativeBecause 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 instanceNow 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 😀