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

[Carl T. Miller]

Robert Meier wrote:
>> 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.

No, we use the same CVS server for all three.  Developers
update CVS and apply version numbers.  When one version
is ready to be tested, a tag is applied and it is exported
from CVS to a staging server.  If QA approves it, it is
exported to a production server.  If there is a problem,
the previous tag is exported to the production server.

> How was this approach justified to management?

That happened before I got here.  I'm sure it was just a
matter of too many people with their own code on their
own workstations, no individual backups, and no easy way
to rollback if needed.

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

Tags.

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

A manager has to approve anything sent to staging.  The
QA team then verifies that there are no problems.  Basically
they look for broken links on webpages, broken functionality
or errors.

>> 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.

The versioning system should be an easy sell.  If you
can find a case where someone had bad code and hundreds
of hours were wasted because it wasn't discovered quickly,
the auto build system would look good.

>> 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?

We don't have automatic builds yet.  Hopefully will within
the next month or two.  I seem to recall someone mentioning
that we should have regression testing.

>> 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?

Yes, they can run in their own sandboxes.  But their
code must be checked in before anyone else can see
it.  And it will be helpful to the programmers to save
incrementally as they work on projects, although I don't
think this will be a requirement.  They will only limit
themselves if they don't check in frequently.

c