Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Deploying SS stored in GIT via Capistrano?

Go to End

7 Posts   2785 Views


Community Member, 63 Posts

26 March 2011 at 5:40am

Hi everyone,

Like many of you, I'm jumping into GIT. With my latest SS project, I've created the code, pushed to GIT and am ready to deploy.

For the last few years, I've used Capistrano and SVN and it's worked very well. However, in setting up Capistrano for GIT, I'm running into a few roadblocks and wanted to reach out to the community to see what you do.

How are you all deploying your GIT projects? Capistrano? I had a look at: but stilll have a few questions.

Related portion of my Capistrano recipe:

default_run_options[:pty] = true
set :application, '1095'
set :repository, ""
set :scm, "git"
set :branch, "master"
set :scm_verbose, true
set :deploy_via, :remote_cache
set :ssh_options, { :forward_agent => true }
set :git_enable_submodules, 1
set :use_sudo, false


1. On the remote server, the project is checked out to a releases/xxx directory. Then a 'current' symlink is created to point to the latest release. Seems simple enough, however, does anyone know how to build directly to web root? What use is the symlink? Obviously, there are other directories (assets, silverstripe-cache) that aren't in version control and would need to not be touched.

2. Permissions are all tweaked by Capistrano and can't be executed after manually 'mv' the files over. Any way to suppress this?

3. Capistrano adds a number of directories that SS doesn't need/want. 'tmp', 'logs', etc.

Thanks for your time replying. Would love to hear your deploy strategies and trade any Cap recipe tips.



Forum Moderator, 5523 Posts

27 March 2011 at 1:44pm

I'm using capistrano for most of my apps and so far love it. How I have it setup may not be perfectly correct but this is what I have..

1 - You wouldn't want to build directly into the root as then releases etc are available for people to download. What I do (I use virtual hosts) is set the webroot to /sites/sitename/current/ so it points to the current release. Altering the webroot is pretty easy for most hosts.

Regarding the assets dir and tmp cache etc, see capistrano 'Shared' folders. Google for a wide range of solutions (i.e

2 - Permissions are changed to whatever user cap is running as, what I have is a post deploy function which cleans up permissions. You can add functions to your config.rb file and have them automatically run.

  task :fix_owner do
    run "chown -R www-data:www-data #{shared_path}/assets"

3 - Not sure about those directories, I don't get them in my projects. Perhaps it's because I'm using railsless-deploy (which I recommend)


Community Member, 63 Posts

29 March 2011 at 9:16am

Thanks Willr! That's great advice. Been looking for something like that for a couple of days. Much appreciated.


Community Member, 63 Posts

29 March 2011 at 9:51am


Community Member, 24 Posts

31 March 2011 at 11:18am

We've just started using capistrano and have noticed a couple of things.

1) We're trying to deploy without the need to use a maintenance page.
Initially the site was down (very slow initial request) for a couple of minutes as the manifest was built plus templates plus cache. So in order to reduce this time we run dev/build before we symlink to the latest release. We also do a sake request for the homepage so that it's template is built as well. Then change permissions to cache as you mentioned Will. Only then did we link current to latest release. This reduced the first page request down to 12 seconds.

This is too slow for what we're after, and the reason why is that sake creates manifest-cli-script whereas an apache request creates mainfest main.

2) manifest-cli-script vs manifest-main
Why are these separate files? I did a diff on them and the cli had a couple of extra zend_log extensions but apart form that they were identical. Currently in a test version of our deployment script we're copying the manifest-cli-script to manifest-main. This reduces the page request down to 1.5 seconds which is much more acceptable.

I am quite nervous about the copy of cli to main.

Can anyone let me know why there's two separate manifest files?

Am I going to cause something unexpected by copying it?


Community Member, 24 Posts

9 April 2011 at 3:54pm

I think this will need a silverstripe developer to answer this? Anyone?


Community Member, 8 Posts

16 April 2011 at 6:21am

I've been struggling with the manifest file issue myself. After some digging I realized that if you define the manifest file location yourself and force it to use -main for the cli then all "should" be fine. So far I haven't had any troubles. Seems hacky but I'm not sure what else to do. I was copying the file over myself for a while.

So, in my _ss_environment.php file I defined the file:

define("MANIFEST_FILE", getSysTempDir() . '/silverstripe-cache' . str_replace(array(' ', "/", ":", "\\"), "-", dirname(__FILE__) ) . "/manifest-main");

That should work in most cases.

Hope that helps.