[Lin Yue]

We use subversion for all our sites (each developers development sites, test and production).  We have created a makefile to help with that and also help Cloverleaf out so the GUI does not bomb out due to the .svn folders that are out there.  In Subversion the recommended layout is:

project/trunk – development version

project/branches – all branches that have been made

project/tags – all tasg that have been made

When we are getting closer to deploying a new version (not bug fixes) of our sites we create a new branch (copy of trunk at that time).  In our case we name the production branches “production-ccyymmdd”.  The person responsible for migration will then update the symbolic link to the test site in $HCIROOT (like joe_projectname_test) to point to the new production branch in his local subversion tree.  The site is tested and updated to have the appropriate timeouts and other stuff that may differ between production and development).

When everything is ready and approval has been received for the production move, we shut all processes for the site in question down in production and shut down the site daemons.  We update the production server’s copy of the subversion repository for the new production branch, and update the symbolic link in $HCIROOT to point to the new production branch.  We run our makefile (make newsite – meaning the site does not have an exec folder) and start everything up again.

The benefit: If something goes wrong we change the symbolic link back and start the old production branch up.  No time lost.  The branch stays exacly the way it was before.

[Lin Yue]

We use subversion.  All branches we are ready to roll to production are first branched (in subversion this bacially looks like a copy in the “branches” folder … of you adhere to the best practices recommendations).  

This branch is then tested in our test environment and adjusted as needed for production rollout (timeouts etc etc).  

When it is ready to be moved to production we simply run an svn update on our production in the folder for that site in the local copy of subversion and update the symbolic link in HCIROOT to point to this new site.  This way we have instant rollback capability if something goes wrong.

/SVNROOT/sites/site1/

                              trunk/ (this is where all development code is kept)

                              branches/production-20050101 (branch made on 1/1/2005)

                              branches/production-20060101 (branch made on 1/1/2006)

In HCIROOT on our development server:

site1_dev is a symbolic link to /SVNROOT/sites/site1/trunk

In HCIROOT on our production server:

site1 is a symbolic link to /SVNROOT/sites/site1/production-20060101

Apart from this we also load configuration files for some of our things like ODBC connections etc that are named according to the site.  In dev we will load site1_dev.ini and in production it will be site1.ini.  

This whole mechanism works real well for us … there are some complexities.  If anyone is interested just send me an email or PM.

[Lin Yue]

Just to be sure someone who reads this thread sees this:

If you return from your UPoC protocol write proc with:

– CONTINUE: Send OK Procs will be called

– ERROR: Send Fail Procs will be called

You can use this very nicely to KILL a message you do not want.  Simply set the Send Fail Outbound Procs to hcitpsmsgkill.  

If you need more functionality like PROTO (or sending the message to the error database) you can just create your own proc to do that and set the Send Fail Outbound Procs to that.

[Author]

Replies