The DevOps Road We Traveled at Esri

5 min read

This blog post is written by Vince Ingram, senior systems administrator, Esri.

Before I started working for Esri as a technical leader in the application support group, I worked in the finance industry, specifically in the area of day trading. By definition, the focus in this market is on the short term. When I joined Esri, I found an organization that had the opposite orientation – the focus was squarely on long-term success. For more than 40 years, Esri has given customer needs the highest priority, helping it to become the global market leader in geographic information systems (GIS). As a privately-held company, Esri allocates more than 30% of its annual revenue to R&D, a reflection of our long-term commitment to improving and delivering mapping and analytics platform software that is second to none.

Our customer-oriented focus naturally led us in the direction of DevOps because we have a strong desire to turn new ideas into reality for our customers as quickly as possible and as smoothly as possible. To help realize that vision, we launched an initiative to adopt DevOps practices and implement them with the CloudBees Jenkins Platform. It’s given my group and the developers we work with more time to explore improvements and ideas that we previously didn’t have the time to pursue. It’s very rare that you find a solution that works so well for both the Dev and Ops sides of the house. Without it, we wouldn’t be anywhere near as agile as we are now in moving from concept to release.


"It’s very rare that you find a solution that works so well for both the Dev and Ops sides of the house. Without it, we wouldn’t be anywhere near as agile as we are now in moving from concept to release."


Before we kicked off our move to DevOps, we identified several areas in which our development and deployment processes were hindering our ability to deliver. The many manual steps we were performing – at times going file-by-file through a source code repository, for example – slowed the process and were a regular source of frustration. My team handled staging deployment environments, so we were in the middle of every step, and that really slowed our developers. We began automating some of these manual tasks with Jenkins, but just as we were getting more and more buy-in into Jenkins as a job engine, we started to hit limitations, particularly around permissions and plugin compatibility. We also lacked the support we needed as an enterprise – when we encountered a problem we needed someone to call and a defined path to quickly get the help we needed.

We addressed our permissions challenge right out of the gate by setting up folders for each development team with defined roles with specific permissions for team members. With this structure, development teams can set up their own jobs and configurations. If they want to use a new plugin, my team first vets it via the CloudBees Assurance Program to help ensure the continued stability and security of our Jenkins environment and then installs it. We addressed our permissions challenge right out of the gate by setting up folders for each development team with defined roles with specific permissions for team members. With this structure, development teams can set up their own jobs and configurations. If they want to use a new plugin, my team first vets it via the so the development team can proceed. We also now have a direct line to expert support. CloudBees support engineers really know Jenkins, so they can identify the root of an issue quickly, get it resolved quickly and get us back on our way. Their attitude is always on working together with us to find the best way forward, and that includes showing us better methods that lead us where we need to go.


"I now have 30 percent more time in my day to spend on higher value projects because I am spending less time on day-to-day manual tasks."


Our approach is already yielding positive results, including decreased administrative overhead and increased developer productivity, both for our experienced developers and for our new hires. For example, I now have 30 percent more time in my day to spend on higher value projects because I am spending less time on day-to-day manual tasks. And it’s not just me – I believe the entire application support group is more productive as well. On the development side of the house, increased automation has freed up about 40 percent of our developers’ time. It has also reduced tension between development teams and the applications support group, because developers no longer have to wait for us to deploy to staging. When a deadline is coming and our group is engaged with another project, the ability for our developers to deploy software themselves is vital. Plus, the people that we hire now can get right to work on the job we’ve hired them to do, instead of getting bogged down in manual processes and an antiquated way of doing things.

As we move forward, I anticipate continued evolution of our DevOps strategy with support from our team at CloudBees. Working together has really broadened the minds of our group and others at Esri as well. It seems like every week I add another group or team that wants to try something new and that continued expansion will help us deliver on our decades-long commitment to our customers in the years to come.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.