How team structure affects software repository design
You may already know that how Conway’s Law affects the architecture design of microservices using an approach of Domain Driven Design, which is the heart of microservice paradigms. There are already a number of excellent articles on Internet to illustrate the idea, for example:
Recently, I was working on a new software project and found that, to have efficient management of source code, the software team structure also plays a role in the design of source code repositories.
To recap, from Wikipedia, Conway’s Law states that:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”[2][3]
— Melvin E. Conway
In this article, I will discuss the design options and how it best matches the different scenarios of a team structure.
Background
In a typical project, our software engineers develop microservice modules and use automation pipelines to build and deploy the artifacts. We provision infrastructure by using IaC (Infrastructure as Code) software. We are trying to store everything - including source code, infrastructure code and software runtime configuration - in our source code repositories.
I will describe three scenarios for the team structures that may be in place and for each, I will propose a repository structure.
Scenario 1
Team Structure
There are multiple teams for each of their products. Each product development team owns, builds and runs their own platform which hosts the microservices.
Proposed Repository Structure
Each product team sets up repositories for each of the microservices it owns and manages. Each repository includes the IaC code, program source, pipeline scripts and runtime configuration of each microservice.
Scenario 2
Team Structure
A platform team owns and run a single shared platform. Each product development team owns the source code and deploys the software into the single platform.
Proposed Repository Structure
A platform team sets up and owns repositories to host the IaC code, platform runtime configuration and automation pipeline scripts of the platform. Each product team sets up and owns repositories for each of the microservices they manage. Each repository includes program code, pipeline scripts and runtime configuration for each of the microservice modules.
Scenario 3
Team Structure
A platform team owns and runs a single shared platform. Each product development team owns the source code and deploys the software into the single platform. Thankfully, a pipeline team is added to build and manage all the pipelines for both the platform team and product teams.
Proposed Repository Structure
A platform team sets up and owns repositories to store the IaC code andplatform runtime configuration of the platform. Every product team sets up and owns repositories for each of microservices it owns and manages. Each repository includes program code and runtime configuration for each of microservice modules. A new repository, which is owned and managed by the pipeline team, is set up to store all pipeline definition and scripts for both the platform and microservice modules.
Benefits
In all scenarios, each team (product teams, platform team and pipeline team) has exclusive control of its repositories, whereas other teams only have a ready-only access. It provides fully-isolated environments, and teams don’t need to worry about the risk of their code being erroneously modified by other teams.
It also improves efficiency of communication; the communication path of development process just mimics the communication path of the team organisation. For instance, in scenario 3, if either a product team or platform needs to have a request change of the pipelines they are using, they just raise a change request ticket to the pipeline team. After the pipeline team completes the request, they check in the changes to the pipeline repository. The changes will be automatically delivered when the product team next runs the pipeline.
