[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora] Re: Semi OT: Subversion



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 coco merseine nu  Z1aaaaaaa coco merseine nu
-- 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]