1

I am planning to manage an outsourced dev team working on my codebase by having that team work in feature branches for all the work they have been assigned. They would be responsible for merging changes from the trunk weekly. My own team would also continue to use feature branching as required.

Does anyone have any tips based on experience integrating outsourced work using a particular branching strategy?

Don Zacharias
  • 1,544
  • 2
  • 14
  • 31

1 Answers1

2

It has been my experience that when working with outsourced development teams it is best to avoid development processes that involve too many manual steps. If there is confusion about how to resolve a merge issue then they will have to communicate this to you or a member of your insourced team and that will slow everybody down.

Most outsourced teams I have dealt with were in India so you have the time zone difference as a challenge, their work day usually ends when yours begins unless you have a pricey team that works EST, central, mountain pacific times. The communication issues are just killer and most of the time I would come in the next day to find they accomplished nothing because they couldn't figure something out without my direct help.

Merging is generally frowned upon but I have personally only seen it work in close knit teams with intermediate to senior developers.

maple_shaft
  • 10,435
  • 6
  • 46
  • 74
  • 1
    What is your strategy then, to avoid merging? Surely it would be worse to have everyone working in the same branch? – Don Zacharias May 16 '11 at 18:16
  • 1
    No that would not be bad. I only branch code per release, or when a massive change is being made to the application that will take a good deal of time to complete, only merging it after I am sure that it will not affect other development efforts, but this is an exception case. Everybody should work on the same branch together but you mitigate the volatility by following Continuous Integration standards http://martinfowler.com/articles/continuousIntegration.html – maple_shaft May 16 '11 at 18:21
  • We are moving toward Agile, so technically we should be able to branch per release since we'd be shooting for predictable releases. But I can see dates slipping since they will be many timezones away. The project is a customized version of a vendor-supplied classic ASP webapp so true CI will be difficult. Or at least it seems so when I try to wrap my head around it. :) – Don Zacharias May 16 '11 at 18:26
  • 1
    (cont) You can utilize continuous integration by setting up a common development environment that would have the latest code every morning deployed to it so that the team can test the integration of their features. If the build fails it should be fixed by the person who broke the build. If a developers code works on his development workstation but not on the integration environment then you have narrowed down an integration bug and you can begin to address it. Their are a lot of benefits to CI and while it sounds heavy, I cannot imagine an outsourced project without following these standards. – maple_shaft May 16 '11 at 18:27
  • 2
    Ahhh I love those famous words, "We are moving towards Agile" :) Everytime I hear this it is always an organization that does not understand the benefits of Agile, or one where management has a direct aversion to it contrary to the opinions of the developers. I appreciate your situation because I have been in it before. Let me put it this way, forget dates, forget timezones, I have never seen a joint in-house outsourced project succeed without full commitment to Agile and CI. Projects where the organization resisted this that I worked on ultimately involved me redoing the offshore team work. – maple_shaft May 16 '11 at 18:33
  • I am going to add one more tidbit of information here. If you want your offshore team to be effective regardless of Agile and CI processes, be sure to provide them extensive and thorough technical designs and specifications for EVERYTHING you want them to work on and be 110% clear on ALL business requirements. If you don't do this they will not deliver anything of value I promise you. – maple_shaft May 16 '11 at 18:45
  • I think that was why I chose those words :) Thank you for your advice! I'm still skeptical about fully committing to CI for an application we didn't build. And of doing CI on a classic ASP application in general since there is actually no build step. – Don Zacharias May 16 '11 at 18:52
  • There is a deploy step though, you need to deploy the ASP pages, somewhere. It need not be complicated, just set up an IIS server on some box that the entire team can access. You don't necessarily need to even invest time in setting up Cruise Control, I have seen teams that wrote a simple script on the CI dev box that checks out all the files from the branch to a staging area, and then deploys those files to the IIS server. All you have to do when you get into the office in the morning is check on the deploy, make sure it succeeded and then make sure nothing broke. It really is cake! – maple_shaft May 16 '11 at 18:59