Web Operations/Reference Specification/Discussion Pages/Deployment Tool

Overview

This came out of a discussion around weather to use Dreadnot or Captin / 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:

• Chief
• Dreadnot
• Captin / Shove

1. 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 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)
2. 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.
3. The web development team that originally worked on Captain / Shove think that they can provide some resources to continue development for this tool.
4. 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.
5. Both teams feel that the new project can provide the required features.