-
Notifications
You must be signed in to change notification settings - Fork 20
Rails Deploy
Deploying Ruby on Rails is done using Capistrano (on Github), a Ruby tool for specifying deploy tasks, and allowing rollbacks.
You will need ssh access to the OCF apphost server. Refer to internal documentation (prot) for getting access.
You also need SSH access to Github.
The deploy will always download the latest commit on the master
branch of the compserv/hkn-rails
repo. Ask another officer for push access.
The required Ruby version is specified in Gemfile
. This version of Ruby must be installed on your system; RVM is highly recommended to install multiple versions of Ruby simultaneously.
Capistrano is a Ruby tool, with various extra dependencies specified in the Gemfile
. You must install these using Bundler, by opening a shell in the hkn-rails repo and running:
bundle install
To deploy, open a shell in your local copy of the hkn-rails repo.
First push your changes to the main repository (here, named compserv
, this may differ from your fork on 'origin')
$ git push compserv master
Then (assuming your dependencies have been installed with run Capistrano:
$ bundle exec cap production deploy
You may be prompted for your SSH key password, if you added one (recommended, but not necessary).
The five parts of this command are:
-
bundle
: a Ruby environment manager, similar to pipenv. Installs dependency gems (libraries). -
exec
: executes a command in the Ruby environment for this project. This gives access to installed gems. -
cap
: the Capistrano command-line tool. -
production
: a specific target environment, specified inconfig/environments
. -
deploy
: The Capistrano deploy task.
This command will roughly execute the following:
-
Create a release folder for this deploy, named by timestamp (
YYYYMMDDHHMMSS
) -
Download the master branch of
compserv/hkn-rails
- Install fresh dependencies
- Restart the web server (with systemd)
- Restart solr, a search indexing program
If somehow the deploy fails, or the deployed code broken, the deploy may be rolled back to an earlier one:
$ bundle exec cap production deploy:rollback
By default, this will rollback to the very last release. You may specify a specific release timestamp as an extra argument:
$ bundle exec cap production deploy:rollback ROLLBACK_RELEASE=release
Currently Capistrano is configured to store 5 past releases on the apphost server, removing them when there are too many.
If you have no good deploys on the server, or if the rollback task fails, you may revert the commits on Github, and instead deploy a new release:
git revert <commit>...
bundle exec cap production deploy
Capistrano deploys releases in a very structured layout on the apphost server:
~/hkn-rails/
prod/
current@ -> (symlink to current release)
releases/
20181107221905/ (copy of repo)
...
repo/
shared/
... (assets)
migrate/
current@ ->
releases/
repo/
shared/
This is configurable in config/deploy.rb
or config/deploy/*.rb
.
TODO
Homepage
Guide
- Basics
- Recommended Onboarding Pacing Schedule
- Comprehensive Setup (Forking, Cloning, and Dev Environment)
- Setup
- Django Development Tutorial
- Other Software Engineering Useful Topics
- Contribution Procedure
- Layout
- Deployment
- Server Administration
- Git Guide
- Style
- FAQ
- For Maintainers
Rails - unmaintained - leftover to serve as source of inspiration for other wiki pages