Freight is a service which aims to make application deployments better.
Python JavaScript CSS HTML Shell Makefile Mako
Permalink
Failed to load latest commit information.
bin god of grammar Aug 5, 2016
docs Fixing docs Oct 21, 2015
freight Merge pull request #95 from getsentry/fix/date-released Oct 12, 2016
hooks Initial commit Feb 4, 2015
migrations Split TaskConfig off of App Mar 8, 2016
static Added backwards compat url routes Feb 25, 2016
templates Favicon? Feb 27, 2015
tests Add prev_sha support to Shell provider Oct 12, 2016
.buildpacks Switch to redis buildpack Oct 13, 2015
.dockerignore Accept DOCKER_CONFIG environment variable (#92) Aug 8, 2016
.gitignore Add docker config files Apr 1, 2015
.travis.yml Kill irc notifications Sep 3, 2015
CHANGES Initial sphinx docs Mar 3, 2015
Dockerfile Clean up Dockerfile and bump versions of stuff Dec 12, 2016
LICENSE Initial commit Feb 4, 2015
Makefile Install npm dependencies with Makefile Feb 27, 2015
Procfile Fix worker in Procfile Jan 22, 2016
README.rst Convert readthedocs links for their .org -> .io migration for hosted … Jun 11, 2016
alembic.ini Initial commit Feb 4, 2015
app.json Fix description of some configuration variables Aug 12, 2015
conftest.py Add notification debounce Aug 4, 2015
docker-compose.yml Fix up docker support and optimize image Jan 13, 2016
docker-entrypoint.sh Accept DOCKER_CONFIG environment variable (#92) Aug 8, 2016
package.json Make sure we copy favicon.png into dist with webpack Mar 8, 2016
requirements-test.txt Export requirements in external files Sep 2, 2015
requirements.txt Fix up docker support and optimize image Jan 13, 2016
setup.cfg ds => freight Feb 20, 2015
setup.py Merge pull request #46 from thoas/master Sep 3, 2015
webpack.config.js Make sure we copy favicon.png into dist with webpack Mar 8, 2016

README.rst

Freight

This project is a work in progress and is not yet intended to be production ready.

This service is intended to augment your existing deployment processes. It should improve on what you may already have, or help you fill in what you're missing.

The overarching goal of the system is to provide easy manual and automated deploys, with a consistent central view of the world. It's heavily inspired by GitHub's processes (and its Heaven project) as well as personal experiences of internal tools from members of the Sentry team.

It's not designed to replace something like Heroku, or other PaaS services, but rather to work with your existing processes, no matter what they are.

Deploy

Current Features

  • Works behind-firewall (no inbound traffic)
  • Multiple applications. All configuration is unique per application
  • Per-environment deployments (i.e. different versions on staging and production)
  • Workspace management (i.e. whatever your deploy command is may be generating local artifacts, those should be cleaned up)
  • Support for at least Fabric-based (simple shell commands) and Heroku-based deploys
  • API-accessible deploy logs
  • Hubot integration (starting deploys)
  • Slack integration (notifying when deploys start/finish/fail)
  • Sentry integration (release tracking, error reporting)
  • Integration with GitHub status checks (i.e. did Circle CI pass on sha XXX)
  • A GUI to get an overview of deploy status and history

Roadmap

What's coming up:

V0

  • Release state management (know what versions are active where, and provide a historical view)
  • Environment locking (i.e. prevent people from deploying to an environment)
  • Automatic deploys (i.e. by looking for VCS changes)
  • Actions within the GUI (deploy, cancel)

V1

  • Deploy queue (i.e. cramer queued sha XXX, armin queued sha YYY)

V2 and Beyond

Machine-consistency service

We could run a service on each machine that would check-in with the master. This would record the current version of the application. The service would be configured with a set of apps (their environment info, how to get app version). The service could also be aware of "how do I deploy a version" which could assist in pull-based deploys.

Resources