Pantheon Community

Multiple Developer Collaboration

Hi everyone, soon we’ll be changing the way we develop sites as we’ll be having multiple developers working on the same site. Previously, we had one developer per site. I’m curious if anyone has any tips or tricks with multiple developers on the same code base? We do use Pantheon LocalDev, local dev tools like gulp, Pattern Lab, and other tools, and we want to be sure that we’re not stepping on each others toes. Currently, we don’t use a CI process, but I’ve been very curious about implementing one as that seems it may help with this too?

We’ve used Multidev for many purposes before, so I assume it would be essentially a multi-dev for each developer and then you’d have to make sure to merge the code correctly into Dev? Also, how does DB synchronization work? Any thoughts would be helpful, thanks!

2 Likes

In terms of multidevs, I recommend multidev-per-feature rather than multidev-per-developer, as you want the branching and review of items to be about the individual features/changes being added to the site rather than a developer only being able to have one branch out for review.

Working with Github and a CI service is definitely a great way to do this. This exact use case is what we’re developing Dropship CI for.

The scenario here is well described by Pantheon’s build toolks guide and I would generally recommend the github -> CI -> Pantheon workflow. Traditionally the most difficult part of this flow is setting up and maintaining the CI configuration. Pantheon has done a ton of great work around this with the build tools plugin, but if you’re looking for a less involved setup, we’d love some people to kick the tires on Dropship while we’re working on getting it ready to launch.

No matter what tools you use though, CI is definitely a part of a high-quality collaboration friendly setup. The main points are:

  • Don’t commit your compiled styles to your source repo to avoid merge conflicts
  • Don’t ship your compiled source with the repo to make ALL of your git ops faster
  • Use a Git Flow-ish branching model where each feature is a branch that can be reviewed and merged independently
  • Use some kind of config management (built into Drupal 8) that commits configuration to code so you can have config changes run on branch builds automatically.

There are often limitations that make this difficult, but these days if you use D8, Composer, CI, and something like Lando or LocalDev for local setup, its very achievable with a team of devs working with Pantheon.

WordPress can achieve some of this too, but some of the points like config management are just harder to do.

As far as db sync, generally the key is to export your changes to code so the database can simply be pulled down locally or cloned to multidevs and then a configuration import from code applies your new features/config.

2 Likes

Thank you, @dustinleblanc for the detailed explanation! I did figure we would need to investigate CI eventually and I suppose now is the the time. I know we need to do a cleanup of our current D8 composer-based custom upstream (which is a full artifact built locally and pushed to GitHub then to our Pantheon sites) so perhaps I can roll that into a new custom upstream and slowly migrate sites over.

So, how would this all work with a custom upstream? That doc doesn’t mention custom upstreams and we want to maintain a list of contrib and custom modules and themes that we’ve built for all sites and update all sites with the latest versions instead of having to touch each site. I assume this is possible with the new built tools model but in a different way? Would we essentially host our own GitHub master custom upstream that we would … fork to the other GitHub repos per site? Any pointers in that direction would help. And I’ll definitely check out that build tools article you linked and test it out. Thanks!

1 Like

No problem @CodeChefMarc!

How this jives with Pantheon’s upstream model is a good question. Upstreams are a model that work by Pantheon’s distribution through Git and the ability therefore to use Git to pull changes from a common source. I am not sure how best to merge that concept with the Composer concept.

When I think of disseminating things like modules and themes via composer, I think of packages instead of Git repositories. The way Tandem currently works on projects is we more or less have a template repo that we use to initialize projects, but that doesn’t really solve the use case of making an update that we want to federate across sites like a custom upstream does. We’re also doing a lot of work on Platform instead of Pantheon, so that doesn’t 1-to-1 jive with the Pantheon model either.

The way I’d imagine you could do this is to have a composer package that lists your modules/themes as dependencies, and when you have to update something, you update it in that shared package, and then release a new version. The end-sites would then run a composer update to pull the new version of that package, getting the updated dependencies.

I haven’t actually used that model to handle this, but that is how I think it would be done.

Definitely an area to explore still for me.

2 Likes

Gotcha, yup, I remember talking with Steve Perch at DrupalCon about this sort of thing and his theory was we could do exactlywht you suggested too - create a custom composer package that lists all of our custom modules. I’ll look into that. Thanks for your responses!