SVN is a life saver in the multi-developer project world.  Heck, even with just one developer we would recommend it.  The ability to organize code revisions is necessity.  Now mix in the CakePHP framework and we have some developers that chose everything perfect for development.

To start, I really think that many people don’t use SVN properly to organize their code.  I myself am one who was like this.  In the past, we only worked in Trunk.  Great, we had the ability to work on our own working copies of the repo, but beyond that, doing code pushes and managing larger revisions versus simple fixes/updates becomes hard.

Let’s say you are in Phase II of a particular project.   You have just rolled out Phase I and are now working on some new core functionality for the application.  But, the client says, XYZ is not working properly (from Phase I).  So, now the dilemma.  Here we need to make some changes to our SVN Repo, but alls we have is Trunk.  Yeah, we can make the changes, keep track of what files changed (hoping that none of those files have already changed from Phase II) and copy them over to the new server.  This is dumb.  This is not the way it should work.  Let’s look at SVN and how it should be used properly.

First off, we have trunk, branches, and tags.  Trunk, as we talked about before is your core development stream.  This is where all of your major development occurs.  Branches are typically a copy of a trunk from a certain point of time where it is either later merged back in with trunk or disgarded.  Tags are production milestones and are meant to be left untouched.  Lets go a little deeper.

Trunk

After the launch of Phase I, trunk stays how it is.  In fact, trunk will be where your hardcore development is always taking place (of course unless you want to do something experimental, then create a special branch).  So, Phase II development continues on Trunk as Phase I also did on Trunk.

Branches

So, we have launched Phase I into production.  From here, we do an svn copy of our trunk and make a 1.1 branch.  Remember that dilemma we had before?  Well, if a change request is made from the client because of a bug or other issue, we just make that modification to the 1.1 branch.   Now that we made the change there, we can easily re-push our application to production because it only contains the additional changes needed since the last major code push.  We can then use SVN to merge those changes into Trunk so we can be sure that the next Phase implementation will contain these fixes.

Tags

After launching Phase I, we create a Tag right away.  A tag is made for every major push done.  At least that is what we do.  You could also make a tag for every push.  So, let’s say you push the 1.1 branch into production.  You could make a 1.1 tag if you want.  Basically, the Tag is your failsafe.  If something goes wrong, you can always fallback.  No changes should ever be made to a Tag.  No code changes, no merges, nothing.

All of this continues in an everlasting cycle.  It may seem tedious at first, but once you get the hang of it, it is pretty straightforward and you’ll be wondering why you haven’t been always organizing your SVN repos.

Mix in CakePHP

I’m not going to go into technicals about commands to use to achieve what I’m talking about, but let’s start with some basics on how Cake is structured.

First, Cake applications contain a tmp directory.  This directory is used to store model caching, view caching, logs, and other items.  We really don’t need this stuff in subversion.  So, first things first is to have SVN ignore this directory and all directories using “propedit”.

Next, Cake has config files.  Some important ones are app/config/database.php, app/config/core.php, and maybe you even create your own custom config.php you use for your personal configs.  These files should NOT be in your repo.  This is one of the things that makes code pushes harder, if these are in the repo.  An approach that we like to do is make 2 extra versions of these config files.  One called  filename.prod.php and the other filename.dev.php   Obviously, the prod. has settings from production and dev. has settings from development (of course if you checkout and work locally, maybe you will just copy dev. and modify to your needs).  Anyways, the beauty of this is that you now have the config files ready for you when you either A) checkout the repo or B) export the repo for a code push.  After export or checkout, you simply copy the appropriate file to get your app to start working  ( ie.  cp database.prod.php database.php )

You may also want to consider doing the same thing as the above with your app/webroot/index.php because this contains where you set the Cake core location.  This could vary from production to development.

So, now, doing a CakePHP code push can be as easy as this:

svn export svn+ssh://svnuser@svndomain.com/reponame/trunk/app appnew/
cp appnew/config/database.prod.php appnew/config/database.php
cp appnew/config/core.prod.php appnew/config/core.php
cp appnew/webroot/index.prod.php appnew/webroot/index.php
chmod -R 777 appnew/tmp
mv app app.bk
mv appnew app
There you have it.  We just implemented a new release pretty simply.

If you are looking to automate something like this, please look into Fredistrano (http://code.google.com/p/fredistrano/)   We met these guys at the CakePHP Fest in Orlando and they blew everyone away.  They have a nice interface to do something similar to the above.  Something definitely worth checking out.

If you have any comments or suggestions as to our methods mentioned in this article, please feel free to share them.  We are always looking to better ourselves.

Lee Forkenbrock
Partner

Tags: cakephp development, cakephp svn, pushing cakephp applications, svn cakephp

This entry was posted on Friday, March 28th, 2008 at 3:22 pm and is filed under CakePHP, SVN. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.