march - a go deployment tool written in ruby

March is an in-house deployment tool that acts as an insanely lightweight capistrano and allows you to build and deploy a go package to run as a pseudo-daemon on remote servers without any hassle.

It takes a minute to set up and makes your deploy workload almost nil.

setup

Create a march directory containing a single file: config.yml. Add march/build to your .gitignore as that is where intermediate binaries are stored.

In this file, you can specify the following options:

# Specifies the remote path to which march will deploy.
deploy_path: /home/deploy/yourscript

# Specify extra env vars. 
env:
  ENV_FILENAME: /home/deploy/yourscript/.env

# The name of the binary generated by `go build`. 
go_binary_name: yourscript
   
# This is the base property list that is applied to all servers in all stages.
# Anything specified in the config for a specific server will override these defaults.
# e.g. if I created a server below (under stages) and specified go_os: windows, it would 
server_defaults:
  go_os: linux
  user: deploy
  port: 22

stages:
  staging:
    servers:
      - host: staging.yourapp.com

  production:
    servers:
      - host: app-1.yourapp.com
        port: 2222
      - host: app-2.yourapp.com
      - host: app-3.yourapp.com

All files in the assets/ folder in your Go source directly will be copied directly to the server and can be accessed at os.Getenv('MARCH_ASSETS_PATH').

commands

format: march {stage} {command}

• deploy: builds your go package into a binary and uploads it along with some support files to your deploy_path on all servers matching that stage.
• logs: tails the logs of your go program

issues

Feel free to log any issues, inconsistencies, or non-user-friendliness you find on the github issue tracker for this repository.

todo

• Reevaluate the logging system
• Fully daemonize the go binary process so it continues running through server restarts
• Deploy versioning (capistrano-style)
  • rollback to previous deploys
• Zero-downtime deployment
• March currently kills the child process with a SIGINT not a SIGKILL, but maybe there should be a config-specifiable option to send a SIGKILL after a certain amount of time.
• Limit max length of log files (once it is over N lines, archive it to a separate logs/ directory so you can still browse historical logs but don't have to sift through a bunch of them unless you want to)
• Option or requirement to build binary from a branch specified in config for stage instead of just the current working tree