DevOps At JOOR: "Whose Dev Environment Is It Anyway?"
Below is an article originally written by Katie McKew, a DevOps Engineer at PowerToFly Partner JOOR, and published on May 14, 2018. Go to JOOR's page on PowerToFly to see their open positions and learn more.
I'm Katie, a Software Engineer currently doing DevOps (and loving it!) at JOOR, the world's largest digital wholesale marketplace. As a developer and a member of the DevOps team, I've experienced first-hand the importance of knowledge sharing and collaboration between pods (backend, frontend, iOS, or DevOps) within the JOOR engineering team. In this post, I will discuss how we are are creating a healthy DevOps culture at JOOR, including the lessons and changes we have made along the way.
Pinning down the pain points
During one of our tech-team retrospectives, we uncovered that many developers were facing pervasive issues with their development environments, particularly related to the Docker containers we run locally for testing. Heads turned immediately to the DevOps engineers in the room: they architected the environment and, in many cases, devs were counting on their Docker expertise to get unblocked.
This sparked an important conversation — is the DevOps team really the only team responsible for fixing our dev environments? Our DevOps engineers made the architectural decisions (like using Docker) that went into creating the dev environment that developers use every day. To developers who aren't very familiar with Docker, errors can seem esoteric, and only solvable by those who set it up. From a practical perspective, though, there just aren't enough DevOps resources to help each individual developer on a daily basis.
By surfacing this knowledge silo, we were given the opportunity to brainstorm solutions! (Aren't retros great?!)
Communication & Documentation
As anyone who has used Stack Overflow knows, the ability to search for your error message proves extremely effective in resolving issues — as long as the resolutions are documented, too. Our first idea was to crowdsource a "troubleshooting" Confluence page that documents common errors and resolutions. This resource still proves useful today, especially for new devs trying to set up their environments.
For more day-to-day issues, we created a dedicated Slack channel for people to share errors and issues as they encounter them in their dev environment. In addition to providing searchability, Slack allows our team to quickly discover if: A) other people are experiencing the same problem, and it could be a broken master build; or B) the issue is isolated to the reporter's machine, but maybe someone else has seen this issue in the past and can point to a known solution.
Both Confluence and Slack also provide great opportunities for engineers to step up and contribute to the team outside of just coding: they can grow their expertise by researching an issue, and they can demonstrate leadership by sharing knowledge with others.
Breaking Down Knowledge Silos
In recent weeks, our tech team has made strides in our effort to level up the users of the dev environment on the tools and infrastructure used to set the environment up. Our DevOps engineers have held lunch-and-learns — open to the whole company, not just developers — on various concepts like Docker and Kubernetes. These sessions have been helpful not only for seeing how these tools are being used at JOOR, but also for filling in devs' knowledge gaps and providing an open environment to ask questions. Using feedback from developers, the DevOps pod also improved the automated tools that developers can use to diagnose common issues in the dev environment. Both developers and DevOps engineers contribute to the crowdsourced troubleshooting documentation on our shared knowledge-base, and continue to resolve issues in public Slack channels.
Here are some mutually beneficial strategies you can bring to your team to minimize throwing things over the wall, surface issues faster, and resolve blockers more effectively!
- Developers — Pair with a DevOps engineer on solving your problem instead of throwing it over the wall. DevOps can learn from your frustrations and you can document this resolution for other devs.
- Walk a mile in each other's shoes! At JOOR we have the awesome opportunity to do rotations on other teams, so developers can gain DevOps experience and vice versa.
- Read and contribute to each other's documentation. While the DevOps engineers may initially need to lay out the README for setting up the dev environment, they can't possibly know what issues users will encounter while following the instructions. Ask new team members to point out ways to improve the setup documentation after they use it.
- Hold lunch-and-learns and record them! These sessions can serve as valuable resources for new and existing employees.
- Create a tight feedback loop between developers and DevOps to ensure Ops are working on fixing the most pressing pain points. This can take place in a public Slack channel, a full team retro (including ops and devs), asking developers to write and prioritize dev env bug tickets on the ops board, or even sending out a survey to developers to gauge sentiment on their dev env experience.
By implementing these strategies with our engineering team, we have drastically improved communication between pods, which in turn, has improved collaboration and productivity. We've placed greater emphasis on documentation, which has long-term value for both existing engineers and new team members during onboarding. Most importantly, developers feel more informed and empowered to unblock themselves, without feeling like DevOps are the gatekeepers to the solutions. The team shares mutual ownership and responsibility over the dev environment, so issues get surfaced and resolved more efficiently. DevOps culture for the win!
Interested in learning more about working at JOOR? We're hiring! Check out our PowerToFly page.
How to Grow Your Career Without Leaving Your Company: A Conversation with Greenhouse's Lauren Allanson
Lauren Allanson has had three jobs in five years and hasn't had to move offices once.
That's because all of her recent career changes have been at Greenhouse, the hiring software company, headquartered in New York. Lauren began working there as a recruiter, then moved into product management before becoming a project manager.
This edition of our career spotlight series features Caitlin Flint, Group Design Manager at Intuit.
Caitlin's career began at the Advancement Project, a civil rights nonprofit focused on large-scale systemic change to remedy inequity. There, she had the opportunity to work on mapping software for California's first-ever open redistricting process, which ignited her passion for improving people's lives at scale. This made her a natural fit for a role on Intuit's design team, where she has worked for the past six years. Caitlin earned her B.A. in Design from the University of California in Davis, where she specialized in Visual Communications.
A five-step framework for addressing systematic racism at work
The world has changed in the past few weeks.
We're watching corporations and organizations across the world come out in support of Black lives in droves. Many of those organizations are doing so for the first time in their history.
A Conversation with Surescripts' Terri Policy
If evening is rolling around and Terri Policy hasn't yet met her step goal, her Apple Watch dings at her. "I get this little cheering on at the end of the day saying to me, 'You can still do it!' And I think, of course I can still do it. I don't need those little pats on the back to meet my goals, particularly when it is something that is important to me," says Terri.