Deploys

Put mybeast-deploy in front of the deploy command you already use. It runs your script as it is and reports who ran it, from which machine, the commit, its log and how it ended. Each app and environment shows what is live now.

It is for teams that deploy with their own scripts, from a laptop or a CI runner, and want one place to see what went out, find the deploy that broke something and go back to the release before.

mybeast-deploy run --app shop --env staging -- make deploy:staging

How it works

• mybeast-deploy is one bash file on the machine that deploys. It runs your command, which keeps the terminal for its own prompts, and sends its output to Deploys every 2 seconds.
• Deploys, at https://services.my-beast.com/deploys, keeps each deploy and rollback with its log. An app is added on its first deploy; the environments are your project's own.
• The pages show what is live in each environment, every deploy with its log, and the command that goes back.
• Afterwards, a failed deploy, or one whose machine stopped reporting, is told to the project's people. A good one can name its release in Errors.

Your deploy still runs where you start it. Deploys holds no SSH keys and never logs in to your servers, and a deploy runs all the same when Deploys can't be reached.

What you need

• A project with Deploys in its packages, and its environments (such as staging and production), set at id.
• A server key for Deploys, made in the project's settings.
• A machine with bash 3.2 or later (macOS's own will do) and curl.
• The command you deploy with, whatever it is: make deploy, a script, a kubectl or rsync line.
• The app's git checkout to run it from, so the deploy knows its commit. It runs without one too.

Explore the docs