[mdlug] Seeking best practice documentation for "dual-track" development

Robert Meier list1c30fe42 at bellsouth.net
Wed Jun 18 19:57:31 EDT 2008


c

>> The particular aspect sought is what used to be called 'dual-track
>> development (by AT&T, RCA, ...) and I suspect might now be called
>> 'continuous development'.

> I don't know the buzzword, but I've heard of this type of system.
> Currently we have development, staging and production servers.
> Programmers can do whatever they want on the dev servers.
> When a team leader decides a particular version is good,
> it is copied from CVS to the staging server.
> At this point the QA team verifies that everything is right.
> If so, it is passed on to production and checked by QA again.
> We currently use CVS, but will switch to subversion soon,
> since it better handles multiple branches.

If I understand correctly, you use CVS only on the development server.

You copy the "good" code to a third host, the staging server.

You copy the "QA-verified" code to a third host, the production server.



How was this approach justified to management?

How do you distinguish the "good" code?
  by tag? by irreversible copy? ???

How do you distinguish "safe" fixes made on the staging server?



> We are also preparing to start an automatic build system,
> which is key to what you mentioned.

This is an unscheduled (and unbudgetted) goal.
The problem is to justify the effort required
in terms of "new" features, and existing customer-reported bugs,
and to show during development,
daily monotonic progress in terms of new working code.

> Every hour the repository is checked for a new version.
> If it finds one, it builds the new version automatically.
> This allows programmers to see the results of new code within an hour ...

Do you have automatic regression testing as well to catch
integration and interaction bugs beyond syntax errors?

> The programmers use the code repository to update or
> rollback the code.

I assume the programmers can build in their own "sandbox"
or must they check the code in for automatic build before
even syntax errors can be found?

> Incidentally, I'd love to see what you come up with,
> if you are able to share your findings.

AFAIK, I should be able to share findings.
If I forget or don't respond soon enough,
contact me off list for updates.

TIA,
-- 
Bob

  "Never trust a computer you can't throw out a window."
     -- Steve Wozniak




More information about the mdlug mailing list