Preliminary Note
This question is likely to be closed as either off-topic (engineering), or as too broad or list-generating. That said, there is an underlying core that relates to project management, and I will attempt to address that.
Tools Should Support a Process, Not Define One
Your underlying problem is that you have a tool (not identified in your original question) that treats source control across projects as a monolithic repository. While certainly not a best practice, it’s common enough that it’s not inherently wrong. It does, however, often create problems such as the ones you’re experiencing.
From a project management point of view, it is likely that the tool chosen is defining (or possibly constraining) your teams’ optimal processes, rather than supporting the processes that the teams want. When that happens, the best thing to do is document the issues, and then either work as a team (or team of teams) to refine your process or replace the tool.
Work Towards a Cross-Functional or Scaled Team
Again, from a project management point of view, the challenge you’ve identified is that work on the source code can touch areas outside the expertise of a given team. That’s primarily a problem because you now have a set of externalized dependencies on your work, rather than having the necessary skills and expertise within a given team’s scope of work.
That’s common enough, but the goal for most projects should be to minimize externalities and reduce hand-offs and friction points. This may require:
- Changes in team composition.
- Changes in workflow.
- Changes to your estimation and review processes to account for limitations imposed by the organization or your tool chain.
- Changes in the tool chain itself.
There’s no Single Best Answer™ here. It needs to be carefully reviewed by the teams impacted, and approved by your organization, based on your specific context. So, start those discussions!
Splitting Code and Teams to Avoid Conflicting Change Sets
Plenty of source code systems have ways of working across teams, or within a monolithic repository. Invite your team to explore those!
As an example, Git supports concurrent access to large repositories by allowing developers to create small, targeted change-sets on feature branches that can then be rebased or merged onto a main branch. This allows many people to work on the same code base at the same time, and can reduce merge conflicts if the change-sets are small, well targeted, and merged often back to the main line.
Additionally, Git also supports the ability to create submodules and subtrees that enable different parts of the code base to be treated as independent subcomponents, while still treating the overall code base as an integrated whole.
Other source control systems may not be as powerful or offer as many options, but there’s usually a path forward if the teams work together. Communication and continuous refinement of the workflow are essential.
Integrate Modern Software Projects with a Definition of Done
If you aren’t using Git, the general advice for successfully managing modern software projects should still apply:
- Don’t make large, sweeping changes across the entire code base.
- Keep changes small, and as localized as possible.
- Ensure you have good regression tests and continuous integration practices to catch breaking changes before they’re merged to your main line.
- Use flags and feature toggles when possible to limit the impact of breaking changes until the whole code base has been integrated.
- Use wrappers, adapters, and other OOP patterns to isolate changes from legacy code that may still be in use.
Most importantly, if you can’t get away from multiple teams or improve your tool chain, the best thing you can do is to adopt practices from a framework like Nexus that designate an integration team that’s responsible for guiding and/or gating the integration of work between teams. The integration team’s job is essentially to make sure that work from different teams is fully integrated before a milestone or increment can be considered “done.”
If your teams’ current Definition of Done doesn’t say anything about integration with the main line, or integration and regression testing between teams, then this is a gap in the process and should be addressed as such. Whether or not you have a formal integration team, a clear Definition of Done that defines integration as a core requirement is a must-have.
It is then up to the teams to work together to define how they plan to work together, integrate their separate work products into a releasable increment, and prevent breaking changes across teams. There’s no silver bullet here, either; it will require collaboration, communication, and (most likely) changes to all teams’ workflows and tool chains.
