7

We are outsourcing a development to a small team of offshore developers. Our in house process for code review is manual, paper based, based on a waterfall model requiring "big bang" delivery. It cannot be changed. Past experience is these devs are proficient and reliable, however come time to deliver, the overhead of reviews becomes a difficult burden for everyone involved and issues are being found too late.

We use CVS for our source repository. They take a copy of the CVS repo, receiving regular updates to the most recent code base, and use GIT locally to manage their changes. When ready to deliver, send us a tarball of an upto date CVS clone with their work merged into it. We then code review and check it in.

We are looking for a tool chain to support a code review process where we can do regular, light weight reviews outside our inhouse process, so that when the inhouse process kicks in, we can do it "go fast" mode as we have already reviewed most of the code.

Limitations are that there systems and ours are disconnected. We use sneaker net to transfer files between us. The best we can do is have one machine in house that VPN's into their system.

The source is commercial code and cannot be placed anywhere where it is exposed to the internet.

One option they have suggested is Gerrit - which they plan to use on their site. Is there a way to share and synchronise the gerrit database between sites, given the limitation of the sneaker net? Does anyone else have a solution to tis kind of problem?

2 Answers 2

4

yuk, waterfall -> cvs -> git... sounds like its a mess waiting to happen but...

Your best approach for code reviews IMHO is Redmine with the code review plugin. You create a project in redmine and tell it the repository where the code lives, then you can view the code using the built-in repo browser.

The benefit here is that just looking at the repository linked to the project shows you the changesets and the diffs between changes. With the code review plugin, you can then easily mark sections of code with comments. This generates a ticket (ie a bug) in the project.

This is fast and simple, you end up with a set of tickets that can be assigned and tracked. It doesn't require sharing your source code as it hooks directly to your local CVS repo. However, the tickets might be difficult to view if the redmine system is not available to the outsource team, but you can export them to excel or pdfs and email.

3
  • Not quite what I am looking for. If I could import the exported tickets into an installation at the remote site you might be onto something......
    – mattnz
    Aug 11, 2011 at 21:16
  • you could - its only a DB table. Dump the whole lot from a mysql DB at worst, but the export data can be imported too. Go check it out. (or try Trac, but that requires you to run a process against the repo to mirror the revisions into the trac db)
    – gbjbaanb
    Aug 12, 2011 at 20:08
  • Thanks - Now the idea has legs and sounds like it has serious potential. I will go have a play and see what I can come up with.
    – mattnz
    Aug 14, 2011 at 2:07
4

I find this problem odd because of the strange relationship you have with your offshore development organization.

My experiences in working with an offshore development team SUCCESSFULLY is that they integrate 100% into your existing project team, and this includes:

  • Tools - The offshore team should work in the same source control environment as you. Going to Git is a much better choice mind you than CVS however they should better integrate into YOUR source control. You are their client after all.
  • Environments - Why are YOU VPN'ing into THEIR network? It should be the other way around and they should do this to remotely check code into YOUR source control. This gives the added benefit of getting rid of the manual clutter you are suffering from now.
  • Communication - This one is hard and doesn't have an easy answer. The timezone differences are always a huge hurdle.

So in short, the only answer to your pain is the very political process that prevents them from fully integrating into YOUR development team that you identified as "cannot be changed". Any suggestions to improve this messed up situation will be like giving Tylenol for a broken leg. It won't get fixed until these supposed impossible hurdles are overcome.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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