Question

Partner A has been helping us build our website for the past 6 months. We needed additional skill sets so we recently added the help of Partner B. With that said, we needed a solution that would allow us to collaborate on the same code base while minimizing conflicts; but, I feel the solution we are considering adds a layer of complexity and misses git’s strengths.

Our solution looks like this:

Partner A --> DevServer(A) --> StagingServer(A)
                                               \
                                                StagingFinal --> Production
                                               /
Partner B --> DevServer(B) --> StagingServer(B)

In a nutshell, each partner has their own dev and staging servers, we will then push from each partner’s staging server to the final staging server (where we will resolve conflicts) before pushing to production.

Since I haven’t worked with disparate teams before, I am wondering if this is the best approach. If it makes a difference, we are currently git-flow and hosting our code at Beanstalkapp but we are open to using github if that makes things easier.

Thanks!

Answer 1

Merging the code bases right before deploying to StagingFinal is a very bad idea. You now basically have a completely untested code base in StagingFinal, because you can’t predict how the changes of the two partners might interact.

To remedy this problem, either introduce a “DevServerFinal” or merge the code bases before each partner deploys to their DevServer.