Lessons from a Successful DevOps Transformation

Editor’s Note: This is a guest blog post written by James La Spada, senior manager, software engineering, Capital One.

Most people think of Capital One as a financial institution.  Despite that old school line of thinking, we’ve re-architected ourselves as a disruptive technology company … with the best talent and creative technology solutions for our customers.  To achieve that goal, we knew we needed to change the way we delivered and maintained our software, and that’s why we shifted to DevOps.

Prior to adopting DevOps, we were releasing a monolithic update each month.  Our software engineers and operational teams were on a call throughout the night, and more often than not, we had to back-out code because it was victimized by someone else’s bad code.  Although we utilized some automation, we still dealt with a lot of manual effort.

Now with DevOps, we can do blue/green feature releases multiple times a day.  With quality gates built into our pipeline, we know we are delivering good code into our production environment, and our rollback rate is much lower.

Currently, we’ve been focusing on DevOps as a service.  We’ve created an ecosystem of tooling that combines best-of-breed architecture and continuous integration/continuous delivery (CI/CD) practices. Our platform enables other teams to generate their full CI/CD pipeline and GitHub repositories with skeleton code for the desired archetype within minutes.  Developers are delivering a pipeline of infrastructure and application code to production in a single day—with monitoring and log shipping. We’ve seen dramatic improvements in the productivity of our delivery teams because they can focus on getting their code into production instead of dealing with the added burden of writing infrastructure and pipeline code and maintaining governance around compliance.

Of course, we’ve run into our fair share of challenges, and we’ve learned some valuable lessons along the way.  When we initially rolled out our DevOps toolset ecosystem, other teams needed guidance to use our product. We realized that our documentation was lacking, so we ramped up our documentation and online tutorials.  This has helped tremendously, and we’ve seen a high adoption rate.

Also, although we’ve had good customer feedback, we want to deliver enhancements that customers like.  So, we assigned someone to focus on product features that will help improve the customer experience and ultimately boost our Net Promoter Score (NPS).

Although we deliver features quickly, we are still only a team of six, and it’s challenging to ship new features to support our entire line of business (LOB) of 800+ developers.  Since we’ve always treated our projects as internal open source, that was our solution. We’ve asked other teams who work on new features to inner-source their work. Today, most of our new functionality comes from our inner-sourcing community.

I’m excited to share more of Capital One’s DevOps journey at the DevOps World | Jenkins World 2018 conference, September 16-19.  Be sure to attend my session, “Banking on DevOps - Real World Lessons in CI/CD from Capital One and CIBC” on Wednesday, September 19 at 2:30.