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.
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')
.
format: march {stage} {command}
deploy
: builds your go package into a binary and uploads it along with some support files to yourdeploy_path
on all servers matching that stage.logs
: tails the logs of your go program
Feel free to log any issues, inconsistencies, or non-user-friendliness you find on the github issue tracker for this repository.
- 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