A Work In Progress
This is going to be the sloppiest, soggiest repo in the world for a while.
Forked from mislav, git-deploy was rewritten with the hopes of making it easier to setup, deploy, and maintain a server running a git deployment strategy.
- Uses a gem binary and a basic hook wrapper to allow for easy updates
Capistrano strategy for smart git deployment
Let's set up a straightforward, Heroku-style, push-based deployment, shall we? The goal is that our deployment looks like this:
$ git push origin production
Assumptions are that you are using git for your Rails app and Passenger on the server. For now, we're going to deploy on a single host.
To get started, install the "git-deploy" gem from Gemcutter.org.
This is not "yet another Capistrano strategy". Capistrano is only used for setup, after which it's all git hooks (see detailed description in "Deployment"). This actually replaces the default Capistrano recipe (which is not loaded) with only a basic set of tasks. If you have more advanced deployment (multiple hosts, many "after deploy" hooks) then this library cannot suit your needs at present.
Create a git remote for where you'll push the code on your server. The name of this remote in the examples is "origin", but it can be whatever you wish ("online", "website", or other).
$ git remote add origin firstname.lastname@example.org:/path/to/myapp
The "/path/to/myapp" is the directory where your code will reside. It doesn't have to exist; it will be created for you during this setup.
Create/overwrite the following files in your project:
config/deploy.rb (entire file):
# set to the name of git remote you intend to deploy to set :remote, "origin" # specify the deployment branch set :branch, "master" # sudo will only be used to create the deployment directory set :use_sudo, true # the remote host is read automatically from your git remote specification server remote_host, :app, :web, :db, :primary => true
require 'git_deploy' load 'config/deploy'
Test it by running
cap -T. You should see several deploy tasks listed.
Run the setup task:
$ cap deploy:setup
This will initialize a git repository in the target directory, install the push hook and push the branch you specified to the server.
Login to your server to perform necessary one-time administrative operations. This might include:
- set up the Apache/nginx virtual host for this application;
- check out the branch which you will push production code into (often this is "production");
- check your config/database.yml and create or import the production database.
After you've set everything up, visiting "http://example.com" in your browser should show your app up and running. Subsequent deployments are done simply by pushing to the branch that is currently checked out on our server (see step 4.). The branch is by default "master", but it's suggested to have production code in another branch like "production" or other. This, of course, depends on your git workflow.
We've reached our goal; our deployment now looks like:
$ git push origin production
In fact, running "cap deploy" does exactly this. So what does it do?
The "deploy:setup" task installed a couple of hooks in the remote git repository: "post-receive" and "post-reset". The former is a git hook which is invoked after every push to your server, while the latter is a custom hook that's called asynchronously by "post-receive" when we updated the deployment branch. This is how your working copy on the server is kept up-to-date.
Thus, on first push your server automatically:
- creates the "log" and "tmp" directories;
- copies "config/database.example.yml" or "config/database.yml.example" to "config/database.yml".
On every subsequent deploy, the "post-reset" script analyzes changes and:
- runs "rake db:migrate" if new migrations have been added;
- sync submodule urls if ".gitmodules" file has changed;
- initialize and update submodules;
- touches "tmp/restart.txt" if app restart is needed.
Finally, these are the conditions that dictate an app restart:
- the database has migrated;
- one or more files/submodules under "app", "config", "lib", "public", or "vendor" changed.
The output of "post-reset" is logged to "log/deploy.log" in your application.
It's worth remembering that "post-reset" is done asynchronously from your push operation. This is because migrating the database and updating submodules might take a long time and we don't want to wait for all that while we're doing a git push. But, this means that when the push is done, the server has not yet restarted. You might need to wait a few seconds or a minute, depending on what you pushed.
In the future
Next steps for this library are:
- Support for deployment on multiple hosts. This is a slightly different strategy based on git pull instead of push; something in-between regular "remote cache" strategy and the aforementioned
- Better configurability
- Steps forward to supporting more existing 3rd-party Capistrano tasks, like that of the EngineYard gem
- Support for multiple environments on the same server (production, staging, continuous integration, etc.) sharing the same git repo, so you don't have to push same objects twice
- Automatic submodule conflict resolving