You are here

Steps to CI/CD

How KeyBank achieved continuous integration and delivery

public://default-article.png
Christopher McFee, Director of DevOps, KeyBank

DevOps has brought fundamental, positive changes to how we deliver software at KeyBank. But getting there required that we take a series of incremental steps.

KeyBank's DevOps journey started in 2015, when a small group on the infrastructure team decided to partner with the online banking delivery team to increase delivery velocity and get customers onboard with a new online banking experience.

By using containerization and test automation, we reduced the time it takes to deliver infrastructure from months to minutes. This includes platform-provisioning activities, such as operating system installation, platform installation and configuration, and testing cycles. Once we could provision infrastructure, platforms, and applications—and run through a battery of tests quickly—we were ready to implement continuous integration and continuous delivery practices to provide our delivery teams with fast feedback.

By following these practices, we helped deliver the new online banking system months earlier than anticipated. This gave us confidence that we could deploy on a more frequent basis, and we were ready to try to roll these methods out to a broader constituency.

[ Get Report: The Journey to Enterprise‐Scale DevOps: Becoming DevOps Determined ]

First steps: Building the teams

Before we could get too far, however, we needed to build teams that would help us scale to other areas of our organization. Building the teams within this group proceeded gradually over the course of the last few years as we experimented with the right mix of focus and skills.

One of the core tenets of our group is to help all of our teams to focus on the "three ways" outlined in The Phoenix Project: flow, feedback, and continuous learning. Through our knowledge-sharing, we consult with teams; educate them on processes, and help them continue to learn and grow. In short, we wanted to provide DevOps as a service to the teams.

We also needed to get a handle on all of the other work that all of the teams within our group were involved in, so we started by making our own work visible. Once we could see the types of work that our teams were involved in, we began to see the affinities and could add structure around them.

This was key to providing a safe environment where team members could experiment. We landed on the following teams (capabilities): continuous integration/continuous delivery, cloud-native, and digital intelligence. The latter consults with our development and delivery teams and shares knowledge. It allowed us to consult with our internal delivery teams and share knowledge across our delivery teams. 

These new technologies and processes are core to our digital transformation. They have reduced the time, effort, and costs required for application development, testing, and release, while ensuring stable operations.

[ Special Coverage: DevOps Enterprise Summit London 2019 ]

Rolling out CI/CD

The continuous integration and continuous delivery (CI/CD) team continues the work that we started in test automation. Working hand in hand with our development teams, we helped to create automated application pipelines. These pipelines take advantage of integrations available with modern source-code repositories to automatically run application builds and tests when developers check in their code.

Additionally, by using the zero-touch, on-demand infrastructure available from our cloud-native team, we are shifting our automated functional, integration, and performance tests to the left in the software delivery lifecycle. Within minutes, our developers can get the feedback they need to reduce the potential negative impact of code changes.

The digital intelligence team gathers and correlates data that aligns with our strategy from our systems, applications, and network devices—including user experience, lessons learned, and events—located in all environments. This helps us make data-driven decisions.

One example of this digital intelligence is the automated build and the test results that we analyze to drive meaningful insights into the status of our applications—and increase collaboration between teams. By getting these results early and often, we can ensure that all of our systems remain healthy and reliable, perform at the desired level, and deliver the best possible experience. 

Creating the support structure needed to scale and grow DevOps practices continues to be a focus for us as well. And our cloud-native initiative is a continuation of the work that we started with containers. We needed to provide end-to-end automation to deliver infrastructure (compute, network, and storage) and to provide platforms to our partners with the transparent ability to embrace cloud technology and concepts.

These new technologies and processes are core to our digital transformation. They have reduced the time, effort, and costs required for application development, testing, and release while keeping operations stable.

[ Partner resource: Take Security Journey's first two white belt modules for free. ]

How to get started

Visualizing and evaluating the work should be your starting point. When you can see the work your teams are doing, you can make modifications as necessary to prioritize planned work. And you can see what kind of unplanned work your teams are involved with.

When you can visualize the work, you can begin to put the support structures in place that make sense for what you want to accomplish. Those structures vary depending on your organizational context and culture.

Just remember: It takes time to make even incremental changes. Change can be difficult, and it takes practice. Allow your teams to feel safe to experiment in order to test their assumptions and hypotheses.

Want to know more? Attend my conference session at DevOps Enterprise Summit: London, where I'll offer more insights into KeyBank's DevOps transformation. The conference runs June 25-27.

[ Webinar: Paving the Last Mile to Production: Putting the "O" in DevOps ]