arethusa-configs continuous integration

[balmas]

source repository https://github.com/alpheios-project/arethusa-configs

Rakefile build tasks compiles json files and places compiled versions in dist directory Rakefile release task calls build bumps version # in the VERSION file and pushs everything to github

Current deployment process:

1. new/updated config files are submitted via PR against master branch
2. start build server and login over ssh
3. cd arethusa-configs
4. git checkout master
5. git pull
6. rvm use 2.0
7. rake release
8. For each changed file: . scp -i ~/.ssh/perseidskey.pem dist/<filename> deployer@www.perseids.org:/usr/local/arethusa-configs/dist

[balmas]

Ideally we would also have automated tests which can be used to verify a merged PR won't break anything, but current lack of these tests should not delay the CI implementation

[balmas]

Minimal build from scratch requires ruby 2.0 and bundler. See .travis.yml file.

[balmas]

Here's what ideally I'd like the Capistrano deploy task to do:

1. pull files from master branch on github
2. run the build task locally to compile the JSON files (as the resulting deployment is not a ruby app, we should not require availability of rvm and ruby on the remote deployment server)
3. add and commit the contents of the dist directory and push to GitHub
4. create a release tag on GitHub
5. copy the release tag to the deployment server
6. unpack the release zip to a new directory
7. make the newly unpacked directory the production directory, keeping the last 5 directories around for rollbacks
8. restart Apache (we also need to make sure that Apache server is correctly informing clients that the files have changed)

The capistrano rollback task should

1. rollback to the prior release (with option to rollback further)
2. restart Apache (again making sure that the Apache server is correctly informing clients that the files have changed)

[balmas]

http://stackoverflow.com/questions/5735656/tagging-release-before-deploying-with-capistrano

[balmas]

For clarity, let's break this down into two pieces: build a release and deploy a release

To build a release we need to do the following:

1. git checkout master
2. rvm use 2.0
3. bundle install
4. bundle exec rake build (this updates files in the dist directory)
5. git commit
6. git push
7. create release
   1. at a minimum, this can be accomplished via the GitHub API, may be a better way, I'm not sure. e.g.POST /repos/:owner/:repo/releases (See https://developer.github.com/v3/repos/releases/#create-a-release)

We would like to manage the build on Jenkins.

To deploy a release we need to do the following:

There are two options: 1) deploy only the dist directory by coping its contents to the deployment location on the remote apache server 2) deploy the entire repository, and have the apache server configured to serve only the dist directory

In either scenario, we must:

1. checkout the specific release from github
2. deploy
3. restart apache after deployment
4. enable rollbacks

In the case of this particular application, it makes very little difference to me which approach we take. The default behavior with Capistrano seems to be simply to deploy the entire repo. The latter approach simplifies the capistrano task in favor of a slighly more complicated apache config. The former approach is the reverse.

We would like the deploy task to be dependent upon the build task.