With cloud services becoming the new normal, businesses are trying hard to select the right cloud technology that offers seamless and efficient migration. Oracle Cloud Infrastructure (OCI) allows businesses to easily move workloads without the risk of losing or altering aspects that have so far worked for the businesses.
Oracle’s latest offering OCI has been designed to provide a simple migration process for businesses and to integrate with the most popular programs, applications, and tech stacks available. The combination of OCI’s Continuous Integration (CI) tools with its existing Continuous Deployment (CD) capabilities render a complete end-to-end CI/CD platform for businesses.
Developers can submit source codes to a DevOps code repository, use a build runner to produce and test software artifacts, send them back to these repositories and deploy as applicable. It also has the following advantages.
- OCI DevOps platform is a developer-centric, end-to-end continuous integration and deployment (CI/CD) platform.
- Developers have a full CI/CD platform to accelerate and optimize software delivery on OCI due to the availability of code repositories and build pipeline capabilities.
- Developers can quickly create, test, and deploy software applications in the cloud.
- Customers need not worry about the production and deployment of releases or the issues that occur during change.
- OCI DevOps lets developers keep the code in private Git repositories and link to external code repositories as needed.
- The switch to OCI platforms after migrating an existing application from on-premises or another cloud to OCI is seamless. The OCI DevOps solution is adaptable enough to operate with all existing CI/CD processes.
- In the event of a move and the necessity to preserve the existing CI workflow, businesses can migrate the deployment process to DevOps and coordinate their release stages with DevOps deployment pipelines by initiating deployment from an existing CI pipeline.
- OCI DevOps service is integrated into the OCI platform itself. For instance, a business can set up access for the team with Identity and Access Management (IAM) users and rules against handling them in a separate CI/CD platform.
- Deployment strategies in this platform can help DevOps teams specify details of deployment to production. Admins can make a choice between the risk of delivering a new release and its influence on new users and the infrastructure overhead required to implement an alternative deployment strategy.
DevOps helps developers create a new cloud-native app or move a current project to OCI, as well as get them to market faster. Developers can use the DevOps service to automate various aspects of the software delivery lifecycle, allowing them to deploy features faster and with fewer errors.
Gemini Consulting & Services can help you safely and frequently release software applications with OCI DevOps. Contact us to learn more about how OCI DevOps can enhance your business performance.
CI on OCI DevOps consists of two main components – the Code Repositories and Build Pipelines (linked to components introduced earlier for CD – Artifact Registry and Deployment Pipelines). Build Pipelines use other OCI services, such as Vault, Notification, and Logging to build on the same underlying framework of IAM (users, credentials, permissions, dynamic groups) and IaaS (Network, Compute VM).
OCI Code Repositories are similar to GitHub, GitLab, or Azure DevOps that can be accessed in a secure manner. Charges are applied for storage only – no additional charges for the Git repo overhead. The repo can be accessed through a simple, straightforward browser UI and can be used to search for sources, commits, and pull requests as well. Users can build an OCI Code Repository as a mirror for another Git repository on GitHub. Changes made to the existing Git repo get replicated to the Code Repository on OCI. This quickens up the build process. Each time the build needs to fetch sources from the repo, it can get done faster.
A build pipeline is a process that is triggered – manually or by an event in the code repository – and executes whatever is assigned. The four types of stages are – managed build stage, deliver artifact, trigger deployment, and the waiting phase. It is possible to add multiple stages to a pipeline build that can be executed in a sequence or occur in parallel.
The delivery of artifacts takes the output from a managed build stage and stores them in an artifact repository, either the OCI Container Registry or the Artifact Registry. Trigger deployment starts an OCI DevOps Deployment Pipeline and passes exported variables from the build stage for use in the deployment. The managed build stage is a more elaborate process where a build server is fired up, and triggering sources are cloned from a code repo to this build server. Environmental variables are set up based on conditions, and standard and user-defined input parameters. Further, additional artifacts required for the build process are downloaded to the build server and Linux Shell commands are executed to produce the output.
A lot more flexibility is on the cards regarding the build server– both its size and its starting composition. Teams will be able to compose a custom build server to use in specific build stages with preinstalled runtimes (Node, NPM, JDK, GraalVM, Maven, Python) and tools desired to be used in specific build pipelines. (JUnit, Jest, SonarQube).
While OCI DevOps is a free service, it will attract charges for the build server, the pay-per-use compute costs and the network traffic outside OCI.
