Call a Specialist Today! (02) 9388 1741
Free Delivery! Free Delivery!

The Latest NetApp News
Product and Solution Information, Press Releases, Announcements

NetApp IT Perspective: Automating how apps get onboarded onto DevOps platform
Posted: Thu Jul 09, 2020 11:48:06 AM
 

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.

Using APIs, ServiceNow then hands off to Red Hat CloudForms, which invokes Ansible automation. Ansible Tower performs four key routines.

  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.”

With recent updates to this automation introduced in version 3.5 of the CloudOne platform, a full end-to-end CI/CD pipeline is ready to go with minimal additional configuration required; however extension hooks are available as well, enabling an application team to further customize the build and deployment processes according to their needs. Even without any changes or additions to the CI/CD pipeline, a complete end-to-end flow is available that allows full control with approval steps along the way and quality checks, including critical security scans, before code is released to production. To learn more about this process, read my other blog, “Rapid, Frequent CI/CI with CloudOne DevOps Platform.”

 
« Return to News List