As more federal agencies move towards digital transformation and mission critical activities become increasingly complex, agencies are removing the siloes that currently exist in IT and transitioning to a collaborative, agile approach to software development utilizing DevOps. When it comes to embracing this new approach to software development, some organizations have jumped ahead of the pack – NetApp being one of them. The IT team at NetApp created an internal DevOps environment called “CodeEasy”, which automates the process of provisioning development and QA workspaces for approximately 2,000 geographically dispersed developers.

As agencies and organizations alike continue looking for ways to cut bottlenecks, provisioning delays, and lack of proper testing from the software development process, DevOps has been the answer. DevOps connects operations teams with developers and business staff in order to deploy, manage, and support software development that is better aligned with mission goals and timelines, in turn creating cost efficiencies.

The Tech ONTAP team at NetApp recently sat down with Kumaraswamy Namburu, manager of build release engineering, to discuss why the company decided to aggressively embrace DevOps and how other organizations can benefit from making their own transitions. We thought you’d benefit from it, so continue reading for the full interview below:

TOT: Why did the NetApp engineering and operations teams decide to adopt a DevOps culture?

Namburu: At first, it was the time savings. Years ago, each of our 2,000 developers used to spend several hours creating sandboxes, doing builds and compiles. The processes they used were inconsistent, which threatened to slow our development cycles, introducing risk and uncertainty. We also realized that our methods at the time weren’t scalable—we had to make a change.

TOT: How has DevOps changed the day-to-day lives of developers and operations staff, and how did you drive adoption?

Namburu: Nothing is in the way of them doing their jobs! Developers are paid to write code—that is what they are best at. They should have self-service, and they should be shielded from any back-end complexity. Once developers saw the value, they came on board quickly. We hit 100% adoption, but it didn’t happen overnight.

TOT: How did the shift to DevOps impact your approach to IT infrastructure?

Namburu: We had to think differently and adopt a different mindset. We are using public cloud where it makes sense, and using NetApp Private Storage to maintain control of our data. To protect our intellectual property, we also built a DevOps private cloud environment. Instead of throwing massive amounts of resources at the problem, we found we could achieve our goals simply by managing our data more efficiently.

TOT: What tools are you using to introduce automation capabilities and save developer time in provisioning environments?

Namburu: We are benefitting from our own technology: clustered Data ONTAP, point-in-time Snapshot copies of file systems, FlexClones, junction paths, non-disruptive operations, and SnapMirror. These technologies integrate with Perforce Helix, the version management system, along with the NetApp home-grown software that we use to automate the entire workflow required to produce a release.

For example, by running one CodeEasy script, a developer can clone any environment and get a full development or QA sandbox with zero storage footprint. They can then replicate the environment to other development sites so that developers and QA teams across time zones can all visualize the code in the same way.

NetApp software, which has been helping developers for years, becomes especially critical when you move to DevOps because it addresses common pain points. Companies that aren’t using these technologies are wasting storage capacity and doing unnecessary work.

TOT: Which stage of the DevOps workflow saw the most improvement from applying NetApp technology?

Namburu: Continuous integration tests (CITs). We run multiple, continuous build every 10 minutes and CITs every 3 hours every day to test changes to application functionality. If a change breaks the build or test, we automatically identify the change that caused the break, automatically back it out, and provide an automated way for developers to reproduce the problem. Because we are using thin clones and snapshot copies for this process, we save on both compute cycles and storage—our DevOps private cloud is scalable for the long term.

TOT: What metrics should an organizationuse for measuring success and ROI with DevOps?

Namburu: It depends on your pain points and what you are trying to achieve. In NetApp’s case, at the end of the day we are measurably improving both time-to-market and code quality. If we had kept doing things the old way, it is unlikely that we would have hit our aggressive development milestones—at least not in the same timeframe. We are also making the most efficient use of our resources, from systems to staff time.

TOT: Do you have any advice for organizations just beginning to adopt DevOps?

Namburu: Focus on the mindset first—not the tools. Is your pain point SCM? Build? Testing? Performance? Supporting developers at multiple sites? Your pain points will largely dictate the tools you choose, but we’ve seen that just about any workflow can benefit from the rich set of APIs and data management services offered by NetApp storage systems.