The Evolution of Continuous Merge

On this week’s episode of Dev Interrupted, co-host Conor Bronsdon and Ben Lloyd Pearson, LinearB’s Director of Developer Relations, detail the evolution of Continuous Merge and the tool behind it, gitStream. Joining the conversation is Nik LeBlanc, VP of Engineering at DevCycle. 

Nik shares the ways his team is using gitStream to streamline code reviews and offers practical advice for anyone looking to implement the tool on their own team. He also explores the somewhat controversial practice of splitting up and reshuffling engineering teams, a strategy that DevCycle has used to great effect. Nik finds that this practice helps balance teams, manage diverse knowledge bases, and de-risk the organization.

Conor and Ben wrap up the conversation by casting an eye on the future, focusing on the potential and direction of gitStream.

“There's a lot of attention being paid to PRs and how long they sit. It's become an important part of a team's working agreements to discuss how long they're willing to let a PR sit before it gets reviewed.”

Episode Highlights:

• (2:50) Splitting and reorganizing dev teams
• (9:20) How DevCycle is leveraging tooling to enable positive change
• (14:50) Why teams are paying "a lot more attention" to PRs
• (17:00) Nik's thoughts on DORA and shipping
• (21:20) Threads & socials to follow
• (23:35) Ben & Conor breakdown their convo with Nik
• (27:30) Applying estimated time to review to PRs
• (31:30) gitStream integrations
• (32:30) The future of gitStream

Episode Excerpt:

Conor Bronsdon: How are you leveraging tooling to enable these changes you're making in team structure and composition?

Nik LeBlanc: Yeah. Okay. So that's a good question. We've done some crazy stuff with Jira, and I know everyone loves to hate Jira. I'm a fan of it; I've learned to love it. Basically, each team has a board; they call it a focused board, and at any given moment, a team is working on one particular epic, and that epic is a feature. So epics equal iterations of features around here. And what they do is, they basically, on their focus board, they're able to see all of the tickets of the epic in question, or they're able to just see the epic in question, and they're also able to see any particular bugs unrelated to epics that have been assigned to their teams. We also have guilds, which is another thing that's been historically difficult to make work well. Guilds can either be an opportunity for discussion about a particular part of the platform or technology, or they can be an opportunity for like-minded people to focus on a particular part of the stack, build up backlogs that are less product focused and more, let's say, technical debt focused or investigation focused. And they can try to slot that work into their team's roadmap. So basically, we have teams established with Jira, and any product work or any project work goes to a team through that. And then we have labels that get associated with guild tickets, and those automatically get assigned to, or those appear on the team's boards as well.

So we've gone through a lot of experimentation with the boards and how to best represent the work at hand for a team and how to basically prioritize what Guild tickets the team wants to pick up and what tickets the team doesn't.

Conor Bronsdon: And my understanding is you're leveraging continuous merge tooling to enable that more frequent deployment. Can you share a bit about how that is impacting this team structure you've developed?

Nik LeBlanc: Yeah. So one thing that we haven't done yet with Continuous Merge or with gitStream, but I'd love to figure out how to like assign PRs to people based on their teams. And I know there are a lot of examples in your docs about how to assign them based on familiarity with the code that's changing or lack of familiarity with the code that's changing, so that's something that we're going to lean into heavily in the very near future.

But what we use it, for now is essentially to estimate the amount of time that it would take to review the PR and drop those labels on the PRs. Merge any depend-on bot PRs automatically or any PRs that just deal with tests or docs. I think that's just a prime example in your docs, and it's worked well for us.

A lot of our DORA lead time metrics are being affected by depend-bot PRs just sitting around and not being looked at. So it just forced us to act on them. So what do we wanna do with these? Do we actually wanna merge them? Or do we just not wanna merge them? So now that kind of took that question away from us, and now it just goes in if it passes tests, which is fantastic.

That's pretty much the extent of gitStream at this point, but it was largely the reason we adopted it, which is because of DORA metrics. We saw blockages in our pipeline, and we wanted to smooth them out, and now I want to use it to basically give people the opportunity to explore areas of code that they otherwise have not yet.