The Spotify model has become a popular example for the right way of doing development.

If a product has a single, main, code repository, like most products have, how do you make squads autonomous and independent?

There is common code that different squads will work on during the same period and if a squad adds a bug, during the release, all the squads' code will be reverted, so all squads are affected.

  • 2
    "most products" have a single repo? not in my experience – Ewan Nov 7 at 16:29

I'm not familiar with the Spotify model, but just glancing through the article you linked to it appears to me that the key to answering your question lies in the Decoupled Releases portion (emphasis mine).

Decoupled Releases

Instead of creating cumbersome rules and processes to manage their releases, Spotify simplified the process to encourage small and frequent releases. They changed the architecture to enable decoupled releases using the encoded embedded framework. Each section of the web browser is like a frame of a website where each Squad can release their own stuff directly. They have three different Squads based on the self-service model.

  • Feature Squad: Focused on one feature area.
  • Client App Squad: Focused on making the release easy in one specific area of the platform.
  • Infrastructure Squad: Focused on making other Squads more effective by providing tools and routines for Squads.

By organizing this way, the "common code" you mention is minimized, if not eliminated altogether. One squad's checked in code should have little to no impact on another squad's code.

  • The question then becomes, how do you approach a product so that you can have something similar to: "Each section of the web browser is like a frame of a website where each Squad can release their own stuff directly." – b2238488 Nov 7 at 16:26
  • 1
    @b2238488 That's a much bigger question which with probably a myriad of subjective answers. Here's one example: How to Build Your Own “Spotify Model” – Eric King Nov 7 at 16:34

I don't believe Spotify has made their branching strategy public, but we can speak generally about how different branching strategies work.

Many application do not have a single branch in their code repository. The two most common approaches I've seen is a dev > test > main approach, or more commonly now, feature branches. In the latter, a team would take a branch off of main, work on a feature, then merge it back in as they complete their work, so they don't conflict with other teams.

That said, there are people who advocate for a single "main" branch that everyone checks into all day. This requires discipline, but isn't really that hard to work in. You will want pretty good test coverage of your code and people should make sure to pull down the latest code and make sure all tests pass before committing. Also, as soon as any build fails, that takes top priority until it is fixed. The only place I've seen teams have problems with this is where it is hard to tell if you have broken another part of the code or where team members aren't disciplined enough and commit code and leave without making sure it builds and tests pass.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.