Les Mikesell wrote:
Ashley M. Kirchner wrote:
Les Mikesell wrote:
What you really want is to have everyone who makes changes use their
own working copy (and perhaps their own test server to view it).
At the moment, that's kinda what's setup. They have their own
local copy that they work on. When they're ready, they check in their
new code to our test server which we then look at and see what works
and doesn't. And only when we approve it, it gets pushed to the live
server. They just need to be able to hit that test server and look at
the changes they made as if they're just browsing the actual site
(through a browser) so we can all get a feel for what the live site
will also look like or behave.
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.
Nobody should have the ability to update code owned by 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.
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.
This is substantially the process we followed in the 80s, it's not new
(and there may be refinements), in an organisation of national
significance. We used panvalet for source code management, panexec to
manage executables, and ACF/II to control access.
The tools aren't that important, the procedures and facilities are.
<moan> If E*Trade followed this sort of procedure, its website would
work</moan>
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
Please do not reply off-list
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
