View source for Web Operations/Reference Specification/Discussion Pages/Deployment Tool

== Overview == 
This came out of a discussion around weather to use [https://github.com/racker/dreadnot/ Dreadnot] or [https://github.com/mozilla/captain Captin] / [https://github.com/mozilla/shove  Shove] as the tool for developers to deploy code to running services.

== Why Captain / Shove ==
=== tl,dr ===
The Captain / Shove permissions model allows for more fine-grained access control than other code deployment tools.

=== The Whole Story ===
When the Ref Spec was first under construction, the code deployment tools under discussion were:
* [https://github.com/mozilla/chief Chief]
* [https://github.com/racker/dreadnot Dreadnot]
* [https://github.com/mozilla/captain Captin] / [https://github.com/mozilla/shove  Shove]

# While Chief is in active use, it no longer has any active development resources.
#* The primary developer was no longer part of the IT web operations group and was not doing any more active development.
#*There were known issues with Chief, such as:
#** Sensitivity to redis issues
#** Reliance on [https://github.com/oremj/commander Commander] (Another home-grown, unmaintained tool)
#** No ability to schedule commands
#** Restricted to a single push / update command
#** Requires manual configuration on the server for:
#*** Per-site, per-environment settings file
#*** Per-cluster main configuration file
#** Multiple deployment methodologies lead to difficulties in upgrading
#** No user permissions model (single hard-coded password and no users)
#** No error handling (only generates a 500 error)
# While Dreadnot is getting active development and use by Rackspace, its permissions model is monolithic:
#* There are no separate levels of access. (There is a single htaccess file.)
#* Separation of privileges is most commonly done via running separate Dreadnot servers.
#** In our case, that would probably mean one server for each dev, staging, and production environment for each project.
#*This could be worked around using magic with fronting Dreadnot with something that would extract relevant information from a given URL to provide some privilege separation, etc. but bolting on these kind of access controls as an "afterthought" usually doesn't bode well.
# The web development team that originally worked on Captain / Shove think that they can provide some resources to continue development for this tool.
# The web operations team feels that this would provide a good opportunity to take a more active role in code development and support of a tool that could significantly improve their own workflow.
# Both teams feel that the new project can provide the required features.