Wade Preston Shearer wrote:
I am interested in opinions on where best to locate a repository.
Concider the following situation:
There are individual development environments for each developer. They
commit their code to the repository. Code is updated on a common "dev"
server from the repository for testing. When updates or releases are
ready to by published, the code involved is then updated on a beta
("staging") server (that identically matches the production servers)
from the repository where it is confirmed to be ready. Once verified,
the code is then updated on all production servers (behind a load
balancer) from the repository.
Myn question is where would you put the repository? All servers have
to have access to it. I like the idea of putting it on the dev server,
but for security, the production servers can currently only
communicate with beta. So, with my current setup, the repository would
have to be on beta.
If you were setting up a system such as this, how would you do it?
If you are using Subversion via Apache and WebDAV, you have all the
Apache tools available to do security. If you want to use all the
Subversion tools for history, merge etc. then it makes a big difference
whether or not two versions of the code are in the same repository,
because that's what determines what automatic tools you can apply.
Given all that, I set up Subversion for DharmaTech's site as follows:
1. There is one repository for each piece of software that we work
with. By "piece of software" I mean software development project
with a release schedule. Thus Drupal and TinyMCE are two pieces
of software since they are developed independently by different
groups. Drupal uses TinyMCE and Drupal brings in its copy of
TinyMCE by using an external reference to the TinyMCE repository.
2. Within each repository, the setup is basically what is described
in the Subversion book:
* vendor/ for the code as it came from the developers, with no
local changes
* trunk/ for the latest stable, tested code, basically the
contents of vendor/ with our modifications
* tags/x.y.z/ for versions of trunk that represent known
fixed points of stable, reliable functionality
* branches/something/ for work in progress. We create a
named development branch for each line of development by
making a copy of trunk/. When development on a branch has
reached its conclusion we merge the changes back into trunk/
(or throw them away, depending :-)
* branches/clientname/ for each client. If we did this on
Fantasy Island we would never need to make a custom code
change for a client. Since we work in the real world,
however, we set up a client by creating a branch for them
from the latest tags/x.y.z version then do what we need to.
If an important security patch comes out, we start by
applying it to vendor/ (if it came from the original vendor)
then merge it in to trunk/, the next incremental tags/../
and clients as needed. This gives us the ability to do an
orderly merge and back the change out if necessary.
Each client's site is a working copy of their branch. If we need to do
development for a client that is in production, we will create a branch
from their production branch, develop the changes on their branch, then
merge the results back into their production branch.
Since our software is free software and openness is one of DharmaTech's
core values, you can have a look at our repositories here:
https://justice.dharmatech.org/svn/drupal/
https://justice.dharmatech.org/svn/civicrm/
https://justice.dharmatech.org/svn/tinymce/
-- Walt
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
