views:

63

answers:

3

Hello All,

I work in an environment where we use SVN for our source repositories. For example my code repository is as below:

//svn
 -folder1
   -file1
   -file2
-folder3
   -file4
   -file5

but when these get deployed to production / testing server => the directory structure is very different and only files need to be pushed => in relevant folder of the target server

ex:

 //d/src/datastream
     -file1
     -file2
     -file3
     -file4

target server doesn't have svn installed. Right now its been done as manual process by copying files across. Now its becoming bit hard to track down the version of the target files copied, as this being done by different developers.

How could this deployment process be automated by pushing files into relevant target folder and keep track of svn versions being pushed.

Thanks

A: 

Not much experience in automating deployment, but hopefully your are tagging your files every time you deploy.

Also, you might want to check out Hudson, which is used to automate such things.

Dennis Miller
+1  A: 

You may be able to write a script to do all of this for you.

The script will check the repository revision of your working copy and record this (along with a timestamp) in a log file on the server. Then, the script will copy over each file to the target directory. Every time a new version gets "pushed" to the server, the log file will have a new entry indicating the time that the server was updated and the revision that it was updated with.

You should be able to write this script in whatever language you choose. Having the command-line Subversion tools installed may make this easier.

You can also include a comment block in the header of your files, and include the values $Rev$ and $LastChangedDate$. When a file gets committed, svn will update these values so that when you check out the file, it will show the revision and date on which it was last changed.

bta
I forgot to mention, to make those `$..$` keywords work, you need to add the `svn:keywords` property to the associated file and set the value to "Date Revision". See http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.keywords.html for details and examples.
bta
A: 

Maybe this would be an alternative:

  • Make a SVN tag when the code is to be deployed.

  • Export the code from the desired tag to a directory

  • Copy/move/delete files in order to match the way it should look on deployed server

  • Make a tar package out of it

  • Copy the archive on the server

  • Put your website under maintenance

  • Unpack the arhive

  • Tests?

  • Deactivate maintenance mode

This could very simply be automatized by a shell script to which you could pass as parameter the appropriate SVN tag name.

mhitza
+1 for tags... Tagging releases has always been key for me. Regardless of automation possibilities.
prodigitalson