Presentation: Evolving Continuous Integration: Applying CI to CI Strategy
What You’ll Learn
-
Understand principles for deciding how to build on top of existing CI tooling to improve the developer experience.
-
Hear a practical approach of building tooling, such as Bitbucket/Jenkins plugins, to iteratively improve the CI process.
-
Learn some of the lessons and challenges we found in evolving our CI strategy in this way.
Abstract
Continuous integration as a practice has come to be virtually synonymous with the tools that enable it. As developer workflows grew increasingly diverse and complex, we saw the need to extend and support continuous integration beyond the commit/test/fix cycle. While our existing tooling generally worked for building commits and running suites of automated tests, we found that reliably building pull requests and simplifying the common cases while still supporting complex configurations still presented challenges.
Inspired by developer feedback and the friction we faced with our existing tooling, we began evolving our continuous integration strategy to focus on increasing velocity, simplifying builds, and providing a more integrated developer experience. This session will explore how we leveraged the best practices and opinions of other CI-first tools, fast feedback and requests from our engineers, and an iterative approach to begin building a new suite of tools to support a diverse set of workflows. We will also dive into the technical considerations and approach we are using to minimize configuration while enabling reliable, traceable builds integrated with our existing toolchain.
What is the focus of your work today?
I'm on the Build and CI team (which is part of the productivity engineering organization) at Netflix. My focus is primarily on the continuous integration phase. We use Jenkins as one of our primary tools, but a lot of what I'm doing is working on building our next phase of tooling for continuous integration.
What's your motivation for the talk?
The talk is focused on the work we're doing, specifically through the lens of how we've approached improving our developer experience, at the point of continuous integration. Instead of migrating to a new tool for the potential benefits of a few new features, we’re focusing on improving the experience by building some of those capabilities into our existing toolset with more first class support.
I think it's a really powerful story, especially from an enterprise background, to show that to improve your process and give developers what they want—a better experience and the ability to build the way they want—you don't have to replace all of the tools you're using. You can leverage what you already have and that makes for a more meaningful and smooth migration.
Who are you talking to? Are you talking to a developer or to someone who works specifically building frameworks or tooling, etc.?
The target persona is someone who works on tools being produced for developer consumption. Whether that's a developer building tooling or someone in a more senior role who is informing some of those decisions, it's people who are thinking about the developer mindset and are in positions where they're trying to improve that developer experience.
Can you give me an example of something you might talk about?
I will talk about, for example, how we built a Bitbucket plugin and a Jenkins plugin to make our CI more event-driven as opposed to using the polling mechanisms that are supported by the existing tooling. We could achieve something resembling that with the existing tooling, but it required more complex configuration and we wanted to move towards a more truly event-driven model. I'll also talk about how we made those decisions and what we've learned along the way.
What do you want someone that comes to your talk to leave with?
The key takeaway is how easy it can be to start improving the developer experience by building on what you already have. Instead of trying to take on a huge migration of builds to a new system, how do we start thinking about places in our existing system we can tweak? Where do we see problems now and how can we start to address them?
People are going to ask you if you push your changes back upstream.
We haven't yet. It's definitely something that's on our roadmap for where we'd like to go, but we're a fairly small team so that hasn't been realistic for us yet.
Last question what technology issue keeps you up at night?
There are so many, but lately I've been thinking more about chatops and the developer experience. I think there are many ways we could be leveraging that model to improve the developer experience and reduce some of the cognitive overhead introduced by our tool chains and processes.
Similar Talks
CI/CD for Machine Learning
Program Manager on the Azure DevOps Engineering Team @Microsoft
Sasha Rosenbaum
Scaling Patterns for Netflix's Edge
Playback Edge Engineering @Netflix