[UPHPU] Source Control Questions

[Lamont Peterson]

On Friday 29 December 2006 07:29am, Wade Preston Shearer wrote:
> > So the company I work for is (finally) hiring some new developers.
> > 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?
>
> First, I would recommend that you use a version control system.
> Subversion and CVS are the two most popular. This allows all of the
> developers to check out the code base into their own development
> environments ("sandbox"), make their changes and additions and then
> check them back in. I would then push to a staging server for final
> testing, from which you can verify that code is ready to be pushed to
> your production servers.

One of the things that Bazaar (baz) & Bazaar-ng (bzr) do for you that CVS 
(cvs) and Subversion (svn) can not, is that each person can commit whenever 
they need to.  With cvs or svn, there is one repository that everyone shares.  
They have to access to that one repository in order to run (almost) any cvs 
or svn commands (and definitely to commit anything) at all times.  If that 
one copy of the repository becomes corrupted in some way, that's it; you'd 
better have good, ultra-recent backups.

With baz or bzr, each person has their own repository (called an archive in 
the parlance of their documentation).  You keep a "mirror" copy on a central 
server, but I can work completely disconnected from the network (like on a 
plane or at home w/o VPN).  You simple mirror your repos to the central 
server when you can/are ready to.  Then, others can merge from your branch.  
Also, there is so server-side code to run; you just need ssh access to be 
able to write and read files from some central storage (i.e. file server).

I've used all 4.  I've used cvs going back 10 years, svn going back about 2, 
baz for 2 and bzr for 1 (it's very new).  I will never put new code into cvs 
or svn again, even if it's a just-me-by-myself project.  Yes, people are very 
familiar with cvs & svn and there are several front-ends already available.  
The paradigm of baz & bzr requires a shift in thinking.  People don't like to 
leave their comfort zones, especially with tools like cvs that required lots 
of effort to learn how to work around all the problems.  cvs & svn are just 
too limiting.

Also, it only took me about 1 hour to get comfortable with baz when I first 
started using it.  baz & bzr are just so much more natural that they are very 
easy to pick up and become productive with.  Plus, once you're at all 
familiar with them, your productivity will be better than if you had "stuck" 
with either cvs or svn.

> > * Each developer should have their own development environment that's
> > independent of everything else.
>
> You can have each developer set up their own environment on their own
> workstation, but I find that that is more trouble then it's worth.

Setting up my own box and maintaining it is trivial.  A programmer for whom 
this is not an extremely minor thing to do is a programmer who doesn't 
understand how the environment they are writting code for works.  The 
intimate familiarity they get with how the environment work and what it is 
and is not capable of is invaluable.  It will pay big dividends to their 
productivity and significantly increase the quality of their code.

I say this from first hand experience in years of working in teams.

> Why have your programmers waste time setting up and maintaining a
> server? That's ITs job.

Not all companies have dedicated IT departments.  Those that probably don't 
have a single person who is anywhere near as familiar with the systems as I.

However, that said, there is merit to having IT deal with some parts of your 
dev teams environment.  For example, a couple of years ago, I was teaching 
classes to the entire IT department for a large bank.  One of the things that 
I learned/that they complained about, was that their in-house software 
development people were idiots.  The IT folks would do all this work to set 
up a dev testing group of systems that matched the needs of production 
(remember, I said this was a bank, so there is tons of *legally required* 
security in there, too).  The first thing the programmers did was strip out 
all the security, write code, hand the apps to IT to deploy and then it would 
take over 6 month's of arguing back and forth before IT could get them to fix 
all the things that wouldn't work.  This shows programmers who have no 
understanding of their environment.

Which kind of programmer are you?  Which kind of management of programmers 
will you have/will you provide?  Sure, if there is dedicated IT staff that 
are responsible for deploying apps, then by all means let them set up your 
alpha test environment.  But developers really should set up and maintain 
their own boxes if you want them to produce workable code.  This works by the 
embarrassment factor, when their code won't run on the alpha test platform.

> I prefer having a development box(es) where 
> the environment is already set up for them (ie: Apache configured
> correctly, database already set up and pre-populated, modules and
> other things already installed, etc). Each developer can have their
> own virtual host here. There are a lot of benefits to this, such as
> being able to view other developers sandboxes and access your own
> from anywhere (without requiring VPN).

Some of the projects I've done in team environments required us to test pieces 
of code integrating with one or more other developer's code.  We simply 
configured the app on our own box to connect to each other.  This was very 
easy as we had our own little DNS world going on, with each dev maintaining 
his own DNS server (it simply had a "* IN A my-ip-addr" record, so the 
configuration was an identical set of files for each dev workstation, 
however, we could add our own records when we needed to).  This worked 
extremely well, as we could all find each other any time we needed to.  Some 
people have suggested/tried to do this with just the /etc/hosts file.  In a 
team with just me and one other guy, this caused more bugs and wasted so much 
time during development to be completely not worth it.  DNS is just too easy 
to not do it.

Again, all of these comments come from several years of first hand experience 
in getting teams to put quality code out the door, on time.

> > * 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.
>
> Good plan. I would also set up a conf file for your applications.
> Then the developer can set custom settings and then exclude that file
> from the check in.

I've already commented on this elsewhere in this thread.

> > * I'd like the ability to review code before it gets committed, to
> > prevent obvious stupidities from getting into production code
>
> Good plan. I am not aware of any automated services to facilitate
> this, but I find peer review to generally be sufficient for
> preventing obvious mistakes.

I've already commented on this elsewhere in this thread, but, since I spoke 
about cvs, svn, baz & bzr here ...

This is harder to do with cvs or svn, but not impossible.  The real problem is 
when you need to reject code.  The "easiest" solution if you are going to use 
these is to manually copy code from separate, per-developer central 
repositories, but that means that all your history is lost, in addition to 
several other problems that make it much harder for a team to work 
coherently.

baz & bzr make this really, really easy.  You simply create a "trunk" (or name 
it whatever you want to) archive that your merge code from per-developer 
archives (actually the mirrors on the central server).

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

Like I said earlier, vimdiff, gvimdiff and kompare are all excellent tools 
that I use regularly.  There are others.

> > * 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.
>
> This is as simple as you have requested. You can do this with both
> SVN and CVS.

I've already commented on this elsewhere in this thread.

Although it is possible with cvs and svn and in fact is not all that painful 
with either, it's still a little easier with baz & bzr.

> > * 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.
>
> I am fairly certain that you can restrict access to files in the
> repository.

Not easily.  The main problem with this is that developers (at least those 
that are good enough to have on your staff) will know how to find the code, 
if it's in the same tree.

In an earlier post of mine on this thread, I indicated that this could be 
accomplished with baz or bzr.  What I would do is to put the archive-mirrors 
for the additional/restricted code in a location where others will not have 
access to it.  This could be a different server (in the case of the 
DB/car-processor authentication data needed for production, this might make 
more sense) or another directory structure.

> > * Expanding upon that, it'd be nice if I could just give someone
> > access to certain parts of the code and not others.
>
> This is also easy with a versioning control system. The code can
> exist in various branches and other chunks that you can specify who
> has access to.

Again, this could be done pretty easily with baz & bzr, but it's not so easy 
with either cvs or svn.  Basically, I would do the same thing as for 
other "restricted" code (that appears just before this part in this message) 
and then use FACLs (see the setfacl(1) and getfacl(1) commands) to control 
access to the archive directories.

Of course, his would work best if your apps are modular in design.
-- 
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/ ]