Rapid, Frequent CI/CD with NetApp's CloudOne Platform

Mohan Raj

July 20, 2020

200 views

Rapid, Frequent CI/CD with NetApp IT's CloudO - Inline Image 1 [tw-ceix]

When introducing our CloudOne platform inside NetApp, we wanted to meet certain minimum viable product (MVP) features including the capability to allow rapid, frequent production change through Continuous Integration, Continuous Deployment (CI/CD). We wanted our developers focused on writing code and rapidly releasing application changes, and not be concerned about other IT services like servers, storage, networks, and more.

With our CloudOne platform, we provide automation for frequent small production application changes. Automation helps to reduce the risk associated with large-scale production deployments while adhering to DevOps principles like moving fast and making small changes quickly. With traditional IT there are change control processes that often involve large changes, with some requiring the application to be taken offline. All of this takes time and introduces potential problems for something going wrong. It is not fast.

My favorite feature of the CloudOne platform is how the development (DEV), stage (STG), and production (PRD) environments are handled at the application layer. In our traditional data center model, the DEV-STG-PRD environments are dedicated and sit idle until used. With the CloudOne platform, these environments dynamically spin up and down as needed at the application layer; the infrastructure and platform reside in the operational production (PRD) environment.

CloudOne platform application onboarding

Our CloudOne MVP introduction occurred about one year ago. The MVP goal was to onboard simple apps onto the CloudOne platform to prove out the technology, test the process, and confirm support roles. During application onboarding, we create what we call a DevOps Workspace and DevOps Host Space.

Workspace: Where developers do their work before an application goes live. For example, developers can create code branches, develop the code, create pull requests and trigger continuous integration builds. It’s where they can test out new features, fix bugs, or try out new capabilities using our standards-based technology product catalog.

Host Space: Where the stage and production application run. Its where continuous delivery releases are ultimately transitioned to. Our goal is to take the work that the developers do in the workspace, and via our CI/CD process, transition the changes to production in the host space.

Putting CI/CD processes to work

Applications are onboarded once. During this onboarding, both the workspace and host space are created so that the CI/CD process can automatically work. Once it’s done, then the development team can use the CloudOne platform to rapidly move application changes to production. This is the continuous integration, continuous deployment (CI/CD) process of our CloudOne platform.

Rapid, Frequent CI/CD with NetApp IT's CloudO - Inline Image 2 [tv-f0fb]

There are three levels of our CloudOne platform for application CI/CD. Our developers do most of their work in the first level (within the workspace) using primarily Azure DevOps. This service provides a full application lifecycle management ecosystem including dashboards, analytics, wiki's, project and Kanban boards. It is where the developer’s code repository resides for the applications and where they work on source code.

When an application developer submits a code change to the code repository, it kicks off an automated application build. The build combines the application stack, along with the code changes, to create a binary that is deployed within the workspace (non-production). Within about three to four minutes—that's how long the automation takes—the developer can see their change to the application running in a container and can determine if the change or bug fix worked. If it has been confirmed that the changes are good, the Continuous Delivery (CD) stage of the CI/CD pipeline takes the binary that is in the workspace and copies it into the stage environment in the host space subject to the appropriate approval. The code change can then be approved for release to production.

Based on role-based authorization in OpenShift and Azure DevOps, the developer, development lead, UAT technician, and even operations, can do the final testing and approvals of small changes. Those involved with the change must be satisfied. Once the final approval is made, then the binary image is moved to production via automation. With OpenShift we can migrate each container one at a time to the new binary image so that the application never goes down. The whole process to implement a change—from the developer working on the code all the way to production—can be less than 15 minutes assuming no delay in approvals.

Recently introduced in version 3.5 of the CloudOne CI/CD pipeline is a Canary release model. This model allows a gradual shift of request traffic from the previous version of an application to the new version, in traffic percentage increments determined by the application owners. In this way, even after passing all prior testing gates, the owners of the application can gradually upgrade the application while monitoring to ensure successful changes before fully committing all workload to the upgraded version.

By adhering to an end-to-end, automated DevOps workflows in CloudOne, our developers can spend their time writing code and releasing changes, not having to deal with infrastructure or platform services. The automation provides the ability for frequent, small production application changes to reduce production deployment risk.

With recent changes to the CloudOne automation introduced in version 3.5, the entire flow of an application from software build all the way to production deployment is handled through a unified set of logic. This logic includes code quality checks and security scans as well as approval gates based on organization roles to allow code to be released to production. In addition, with extension hooks built in, it is now possible for an application team to add steps to the build and deployment processes throughout the flow of the pipeline. These extensions add greater flexibility to enable an application team to insert additional checks and application preparation steps according to their needs, while knowing that the base functionality of the CI/CD pipeline already will handle all of their needs under most circumstances.

I realize it is difficult to fully understand how a development platform works without a demonstration. Please click on this video clip to see how easy it is to fix a bug in a demo application we created called Tiny URL Tool. By automating our release process end-to-end, we can rapidly make a small change to this app without downtime, risk, or duplicated supporting infrastructure.

https://www.youtube.com/watch?v=7W-hpOZIOxQ&feature=youtu.be

The NetApp-on-NetApp blogs feature advice from subject matter experts from NetApp IT who share their real experiences using NetApp’s industry-leading data management solutions to support business goals. Visit www.NetAppIT.com to learn more.

Mohan Raj

Mohan Raj is the IT Senior Manager of the CloudOne Developer Experience at NetApp. Mohan and his team plan, engineer and deploy platforms and virtualized environment solutions. They provide the expertise for migrating legacy systems to cloud, along with the right options for tools and platforms. Mohan has over 25 years of IT experience.

View all Posts by Mohan Raj

Next Steps

Blogs

Brush up on the latest trends and developments in cloud, on premises, and everywhere in between. This is where it all gets real, with a cherry on top.

Get to reading

Community

Explore a wide range of open forums where you can post questions, share answers and just generally get smart on all the NetApp technologies that matter most to you.

Join the discussion