NetApp IT Perspective: Automating How Apps Get Onboarded onto DevOps Platform

Over the past couple years I have been part of an exciting NetApp IT initiative to build a DevOps platform that provides the cloud services, automation, and CI/CD release models that our application development teams need to build cloud native applications. We call the platform CloudOne as it provides one consistent developer experience, irrespective of the destination being private or public cloud.

My team automated the processes to onboard applications onto the platform as well as the continuous integration, continuous deployment (CI/CD) process to rapidly move application changes to production. The onboarding process starts when a development team accesses the self-service catalog (on ServiceNow) to identify the type of application being onboarded, and to make selections around the type of application stack and environment sizing requirements of their application. This begins an automated workflow that updates the CMDB—our single source of truth—so that we don't lose track of any assets that get created during the onboarding process.

1. Creates the repository for all the binaries with jFrog Artifactory, the place where we store all the binaries that get created during the application CI/CD process. It is during this step that the Docker registry, as well as third party registry and Helm charts, are established for the application.  Helm is used to manage Kubernetes applications.   
2. Creates the access groups using email distributions lists (through Active Directory) to do role-based authorizations for OpenShift and Azure DevOps.  Our lists are created using an internal tool called NEAT, NetApp Enterprise Action Tool.  It is important that we have clearly defined roles embedded into the process so that changes are not made in production without proper notification and approval.  It serves as embedded checks-and-balances based on preassigned responsibilities and accountabilities.
3. Configures the Red Hat OpenShift environment which creates and manages the containers.  It manages the quotas, assigns roles and groups, and integrates with Artifactory.
4. Configures Azure DevOps Project to create the developer environment including everything from code repositories to code branching to the CI/CD process itself that gets created for the application.

It takes about 30 minutes to onboard an application through this automated process which creates the Workspace, Hostspaces, and if needed, a Dataspace.

Workspace: Where developers do their work before an application goes live. It is the non-production environment.  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.

Hostspaces: Where the stage and production application run, and where the continuous delivery releases will ultimately culminate. Our goal is to take the work that the developers do in the workspace, and via our CI/CD process, transition the changes to stage and production hostspaces.

Dataspace:  Representing Database as a Service (DBaaS), this provides the productivity, performance, and data security needed for databases.

Upon completion of this onboarding process, both the workspace and host space(s) are created so that the CI/CD process can happen automatically. Once it’s done, then the development team can use CloudOne to rapidly move application changes to production. This is the continuous integration, continuous deployment (CI/CD) process of our platform. To learn more about this process, read my other blog, "Rapid, Frequent CI/CI with CloudOne DevOps Platform.”

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.