How to Involve Multiple Teams in TYPO3 Projects Efficiently

Large organizations and agencies face the same challenge: it’s one thing to get everybody tugging on the same rope—but it’s another to have them pull in the same direction. This is all the more difficult when you have several development teams that need to work together. We are often asked to be an external partner to internal developer teams. People need us to get their development workflows in shape and review their code. Here are the tools we use to maximize productivity in multi-team environments.

You can adopt our approach within a single company, or when involving external teams of freelancers or agencies. Our approach minimizes confusion, shortens onboarding processes, and means no more overwriting each other's code!

Git and Gitlab for code collaboration and change tracking

Git is the version-control system we use for tracking changes to code and collaborating within teams. A developer fetches their own copy of a project’s code, works on their own branch, explains what they’ve done so other developers can understand the changes, and merges their work into the staging environment. We have a wide range of best practices—honed through our work on TYPO3 Core—that minimize errors and maximize transparency. In particular, our “one feature per branch” stops one change holding up others, and helps us debug faster.

Although each developer has their own copy of the Git repository, the repository needs to be hosted centrally so everyone can copy the latest version. We choose GitLab because the code behind it is open source, so it aligns with our values as a company. Alternatively, you can use GitHub, which is closed-source and owned by Microsoft.

Our product managers have a good understanding of Git too, because some of them quite frequently add changes to a project, especially for things like labels and localized strings. This gives them a good understanding of how the development process works.

Local development environment

Our TYPO3 developers often have to modify code, for example:

• Debugging
• Refactoring (optimizing code for performance or readability)
• Adding features
• Installing third-party code (such as a TYPO3 extension or integration)
• Updating TYPO3 Core or extensions

If developers did this on the live site, the chances are there would be outages when things misfire — which would be stressful for everyone involved.

Additionally, only one person would be able to work on the site at a time to avoid overwriting each other or causing adverse effects. There are so many things that could go wrong! Which is why we never do it.

Instead, each developer grabs a copy of the live site, runs it on their own machine, and makes any changes there.

Local test server mirrors live environment

Another advantage of local development is that all code can be tested before being integrated with the work of other developers. Automated testing ensures bugs or breakages that might be easily overlooked can be weeded out. It’s a great help to eliminate bugs before code gets merged because debugging is more difficult if you don’t know which changes are the cause.

To this end, each developer has their own local test server that mirrors the online site. At the click of a button, they can import the live database so the code gets tested in real-world conditions.

Merge request and staging environment

In many projects, our role is to sign off code before it gets deployed. We check the code to make sure it’s in line with the style requirements that make code easier for unfamiliar developers to understand, and eliminate any obvious errors. At this stage, though, we don’t perform functional testing—in other words, checking that the code actually works. (That should be done by the developer themselves before merging, and finally when the code is integrated into the stage environment.)

If the merge request is accepted, the code gets merged into the staging environment—a process that is fully automated. This is where the work of all the team members is pulled together. Even if each individual change doesn’t break anything, we now need to check that everything works when the changes from developers in different teams have been merged together. We thoroughly test for security and functionality, using a combination of automated tests and manual user tests.

Finally, the code can be deployed. We do this automatically: it’s a question of changing a tag in Git.

Adopt best practices to improve cross-team working

Over the years, we’ve learned techniques for standardizing our work. Primarily, this reduces the time developers have to invest when trying to understand someone else’s code—a scenario that is more likely the larger the number of developers and teams. Our top tips are:

• Adopt and apply coding standards: We adhere to the coding guidelines stipulated for working on the TYPO3 project. Consistency within organizations is great because code is familiar to whoever wrote it, but having agreed standards across organizations is a huge bonus. If you hire new TYPO3 developers or change your agency, then they will probably already be familiar with your coding standards, so onboarding is faster.
• Use standardized commit messages: For every Git commit, a developer has an opportunity to explain what they have done. We do these in a standardized format, and link each change to a ticket, so an unfamiliar developer can see exactly what has been done, when, and why. This is a huge help when retracing steps to debug code or make changes in the correct manner.
• Encourage a culture of communication: Alongside code comments and commit messages, communication is key to working together and a pillar within our company culture. Sometimes it’s a question of a friendly tap on the shoulder or picking up the phone to unblock an issue; but be mindful that developers need to concentrate for long periods of time so asynchronous communication should be preferred.

Establish excellent processes to get the most out of your development teams

TYPO3 grows with your needs as an organization, and as your project becomes bigger you are more likely to involve more people—including other teams. A thought-through, standardized process makes it much quicker to onboard new people and to get all teams pulling in the same direction.