[UPHPU] Source Control Questions

Lamont Peterson peregrine at openbrainstem.net
Wed Dec 27 16:16:25 MST 2006


On Wednesday 27 December 2006 02:12pm, Daniel C. wrote:
> So the company I work for is (finally) hiring some new developers.

Cool! :)

> Which is good but it introduces some complications to the workflow -
> which until now has been "ssh in, edit files with vim".
>
> Here's a wish list of things I'd like, can someone point me to the
> optimal solution?
>
> * Each developer should have their own development environment that's
> independent of everything else.

As I mentioned in response to John Tabor's suggestion, I recommend bazaar-ng.

> * The development environment should play nice with using
> $_SERVER['DOCUMENT_ROOT'] to include files.  I'm thinking of giving
> each dev their own vhost for this.

Having worked and ran more than one development team (10+ in some cases), I 
recommend that your devs run everything local on their machine for 
development.  In my case, I always used Linux, but each dev could be allowed 
to pick their environment, if you're OK with making them responsible for 
keeping it running properly.  For me, if a developer couldn't admin his own 
workstation, he didn't get hired.

With each dev working on their own workstation, I also set up an alpha and 
beta test servers.  The alpha server was only accessible to the developer's 
network, while the beta server was accessible to the outside world (customers 
could examine and test the apps on the beta server).  The alpha server would 
have configuration that tightened things down.  The beta server would be 
configured as closely to the production servers as was reasonably doable.

We would also create an "rc" virtual host on the production web servers for 
final testing before sending code live.  For example, if I was ready to 
deploy new code for www.example.com, I would first create rc.example.com on 
the same server that I would be using for the production release.  This way, 
if there was something different about the production server configuration 
from the beta server that caused a problem, we would catch it.

These techniques work so well, that in 7 years, i have *never*, not once, 
broken any production apps or server for any client.

> * I'd like the ability to review code before it gets committed, to
> prevent obvious stupidities from getting into production code

Either baz or bzr will work very well for this.  What you do is keep a 
central "trunk" repository separate from the per-developer repositories and 
merge approved code into it.  Then, devs can merge from that trunk repo.

> * I don't want to look at diffs when reviewing code - I'd like to see
> the old file and the new file side by side with differences
> highlighted.

I use kompare and vimdiff for that.  Both are excellent tools that let you 
interactively "cherry-pick" revisions to include.

> * Production code should be separate from our code repository - I
> should check out the code into our production server the same way
> people check out code to work on it locally.

With either baz or bzr (or virtually any other CM system, for that matter), 
simply create a branch for the "release"/production code when it's ready.

> * I want to be able to keep some files "hidden" from some developers -
> specifically the files that contain our DB password info, credit card
> gateway info, etc.  They would need to stay in the live code and/or
> the repository, but not get checked out along with everything else
> when someone grabs the code.

Best to put those in a separate repo that they have no access to.  I've done 
something similar once before.  I wrote the code to look for certain files 
for the DB and card processing info, but to fallback automatically 
into "demo" or "development" or "debug" (pick your favorite term) mode if 
they were not present, in which case, a different set of files would be used.  
I even created a "fake" card processor (SOAP in that case) that the 
development/debug/testing modes could use with the actual card processors' 
client code (kind of like a unit test).

> * Expanding upon that, it'd be nice if I could just give someone
> access to certain parts of the code and not others.

Don't get hung up on this, it can get complicated in a hurry.  However, the 
simple way is to make multiple trunks that have just certain parts of the 
app.  This will require that you design a "base" module that all the rest 
work with, in most cases.

> In the process of writing this I realized that it's possible that I'm
> heading in completely the wrong direction with some things, so if
> that's the case feel free to point out where my ideas are wrong.

Keeping an open mind is very important.

> Thanks in advance for the help,

HTH.

If you'd like to ask me any more specific questions regarding my experiences 
with large dev teams, email me off-list and I'd be happy to get in touch with 
you over the phone or in person.
-- 
Lamont Peterson <peregrine at OpenBrainstem.net>
Founder [ http://blog.OpenBrainstem.net/peregrine/ ]
GPG Key fingerprint: 0E35 93C5 4249 49F0 EC7B  4DDD BE46 4732 6460 CCB5
  ___                   ____            _           _
 / _ \ _ __   ___ _ __ | __ ) _ __ __ _(_)_ __  ___| |_ ___ _ __ ___
| | | | '_ \ / _ \ '_ \|  _ \| '__/ _` | | '_ \/ __| __/ _ \ '_ ` _ \
| |_| | |_) |  __/ | | | |_) | | | (_| | | | | \__ \ ||  __/ | | | | |
 \___/| .__/ \___|_| |_|____/|_|  \__,_|_|_| |_|___/\__\___|_| |_| |_|
      |_|               Intelligent Open Source Software Engineering
                              [ http://www.OpenBrainstem.net/ ]


More information about the UPHPU mailing list