John Summerfield wrote:
The best approach here is to set up virtual servers for views of the
development working copies. Depending on the web server, you may need
to run these on different ports so several can co-exist on the same
machine. This lets development run at its own pace ahead of QA and
different people can be working on different changes at the same time.
I'm pretty much with Les, but ...
1. A development site that people play with.
2. A test site that is what development proposes QA should have.
3. A QA site, maintained by the QA folk taking releases from testing,
fully as if it were the production site.
4. The production site.
Individuals may have their own sandpit. Always, the next stage updates
from the previous stage's master repo.
I'd say individuals _must_ have their own working copy. There are
different schools of thought on how development should be committed to
the repository, though. Some like to make branches for every change and
merge them to the trunk after they are complete. Personally I think
that is too much work and like to have all new development on the trunk
where everyone can easily update to pick up the changes others have
made. The QA workspace is then periodically updated to pick up the new
work, and when everything is good, makes a tag or branch for the release
and production is updated to that state.
Nobody should have the ability to update code owned by the next stage.
That's not possible with most version control systems. Everyone has
their own workspace, including QA/testing, and they get the revision
they ask for, regardless of what else is happening in the repository.
Generally you just want to pass tags or revision numbers around to
indicate what is ready for the next stage.
Sometimes, the production site will need to have unscheduled
maintenance. Probably, folk at level 1 will generate emergency fixes
against their version of what's in production, and someone in
production, with the necessary authority, will take the fix and apply it.
You should always have release branches/tags so at any point you can
either revert to an exact copy of a prior release or pull an exact copy
of the version you need to fix into a workspace to fix it.
It still needs to go through stages 2 & 3 ASAP. Emergency fixes are
always a risk, and should only be used when the risk of using them is
less than the risk of not.
You still want this committed to a branch so you'll be able to repeat
the procedure.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
