deploy_s3
deploy_s3 evolved out of Movable Ink's deployments, which typically involved capistrano. Over time, the capistrano scripts got heavier and multiple datacenters were added, each with dozens of machines. We used Chef for provisioning, and found that it was impossible to keep capistrano up-to-date with the comings and goings of new machines. A separation was needed.
The deploy_s3 workflow
The goal of deploy_s3 is to separate deployment into two parts: specifying that a new version of code should be deployed, and actually deploying that code to the machines that need it.
A typical deployment would look like this:
ยป ds3 production
Attempting to deploy d836d33
Difference of 6 new commit(s) between de0aed0 and d836d33:
d836d33 Michael Nutt 8 minutes ago ignore our own .deploy
9046842 Michael Nutt 8 minutes ago make bin executable
b2b4038 Michael Nutt 8 minutes ago clean up gemspec
e57b428 Michael Nutt 18 minutes ago refactoring
4fba6fa Michael Nutt 26 minutes ago add commit comparisons
349c4ce Michael Nutt 76 minutes ago first pass at sending to s3
Deploy? ([y]es / [n]o / [g]ithub) : y
Deployed d836d33
deploy_s3 relies on a .deploy
file to tell it where to write the git hash. Right now it is tied to Amazon S3, but using fog it could send to any cloud provider.
Movable Ink uses Chef to push out new code, and Chef can simply read s3 for the revision to know exactly which version to deploy. This allows newly provisioned machines to get the latest deployed version while not requiring changes to the provisioning system every time the project is updated.
History
- 0.0.3 - Fix command-line option parsing to work as advertised.
- 0.0.2 - Always save the full git sha to s3. Many CI and deployment tools always upload using the full sha in the path.
- 0.0.1 - Initial release.
License
The MIT License. See LICENSE.md.