4

In a company working on a long term software project, there are 6 to 9 developers working in the same office.

The development team uses JIRA for bug tracking and CVS (and some SVN) for version control of different Java Web Apps related to the software application.

The team uses REST to communicate between the Web Apps on different servers. The environment consists of Amazon EC2 and Google App Engine Apps, all written in Java, HTML, CSS, and JavaScript.

The development team commits the code every day. Using this strategy, deployments happen every 20-25 days, but they would like to target once per week or once every 2 weeks instead.

When the code goes through testing, the testers find and report bugs, but when the development team fix the bugs and deploy the software, the software sometimes then has more bugs in it because developers working on new features are still committing code to the repository.

Sometimes the sales team or customers find bugs as well on production systems. Our thought is that we could check out a copy of the code that is stable and make changes there.

I suspect this is a problem with how the version control is used, but it could be something else in the process. How should this agile development team of 6-9 people make sure that the releases are both frequent, once per week or once every 2 weeks, and that the deployments are high quality with no regression bugs?

2

4 Answers 4

Reset to default
1

Per my experience, the most productive approach to handle issues like that was to track-reflect-tune the development process in sort of OODA loop. Key tricks are to isolate when needed, have clear checkpoints for dev and QA to communicate ("internal releases" if you wish) and, well, not to worry about what isn't really important.

  • oh and better get rid of CVS. Two version control systems seem to be one too much for the case like yours.

Now, let's take a look at some of the problems you mention...

When the code goes through testing, the testers find and report bugs, but when the development team fix the bugs and deploy the software, the software sometimes then has more bugs in it because developers working on new features are still committing code to the repository.

The only productive way I know to stabilize quality of software to be deployed (release candidate) is to isolate it from main repository (read: dedicated branch, with its own dedicated Feature Freeze and Code Freeze mini-milestones).

  • Note my experience with doing it the other way around, ie with "freezing" main repository while testing for release-candidate code was total disaster.

Sometimes the sales team or customers find bugs as well on production systems. Our thought is that we could check out a copy of the code that is stable and make changes there.

Not necessarily so. Sorry for being vague but I doubt that it's possible to come up with technically precise recipe here. This kind stuff is better to communicate with product stakeholders. One thing dev and QA teams can (should) bring to the discussion table is comparative estimate of efforts involved into patching the older version vs deploying the newer one.

2

Rather than "check out a copy of the code that is stable and make changes there." use branching for each feature.

Set up a continuous integration server. When you check code into the main "dev" branch it autobuilds to your dev server.

When you have a new task/feature/etc you branch the dev code into a feature branch. Develop, then merge back into dev.

You also maintain a QA/Test branch, again, it has autobuilds setup to deploy to your QA/Test server.

Each feature can be deployed independently to dev then to QA.

Access to check in to the QA branch needs to be controlled. So that if QA starts testing, no more can be moved there until they have signed off, and merged the QA branch into Production (or a Staging step in between)

This way devs don't clobber what QA is trying to test. And it only goes to Prod once QA signs off. Then, once they sign off and it's deployed to prod, you release another batch of features that are ready into the QA branch for them to QA.

Lather, rinse, repeat.

4
  • Thanks for the feedback, continuous integration is a great suggestion, as is auto-building. I'm not clear on how to deploy individual features because Java packages web applications into a WAR file, which means the entire build is deployed live. We try to mitigate by separating components into modules on different servers, but they still require complete replacement of the WAR files.
    – jmort253
    Commented Oct 12, 2011 at 22:41
  • You deploy individual features by having several branches of source. You then merge the source for that feature into the branch you want it to be a part of. Then continuous integration builds and deploys your WAR file.
    – CaffGeek
    Commented Oct 13, 2011 at 13:29
  • Do you have any visual representations of what this looks like? When I think of a branch, I picture a complete copy of the entire source code, not just a single feature. Thanks!
    – jmort253
    Commented Oct 20, 2011 at 14:53
  • @jmort253, it is a copy of the entire source code. But the changes you make to it are for a single feature. So that a diff between the initial checkin of your branch, and the result when the feature is complete contains the changes that implement that feature. Then you're able to deploy that feature into any tree of code.
    – CaffGeek
    Commented Oct 20, 2011 at 15:38
1

All I can suggest is a tighter feedback loop, via

  • unit or integration testing - initially aimed at defects and common integration pain points.
  • a continuous build that will trigger on every check in that runs unit and integration tests
  • a 'fix the build' type culture in the team - "always striving to get the light green"
  • no code silos - as much as possible, all developers should be able to work on any problem or build failure.
  • deploy often to a demo version of the application(s) that developers/BA's can use to shake out new features before they hit the test team.
  • a new defect, as well as getting fixed, also gets a test that focuses on that problem.

I think you'll find that doing these things will allow you to reduce the number of bugs hitting the testers.

1

You should go read some material about working with branches. I'd keep separate branches for old versions, current and upcoming version, and force all development into feature branches; none of your "stable" branches should ever be broken.

I suppose tooling is a large part of what's missing for you guys. Branching and merging is a bitch with SVN and CVS. I'd push for a move to Git.

1
  • Agreed, especially with CVS. Haven't done much branching in SVN yet. Thanks for your response.
    – jmort253
    Commented Oct 12, 2011 at 22:44

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.