The Developer processes Work Cards, develops them and deploys them to production.

Those live on the Work Board.

Those are the task Developer may want to perform.

Development as usual

Open current task

Open current Trello card in browser:

bb t curcard

Move on to the next task

Move on to the next (Trello) card with:

bb t next


  1. Inspects To Do on the Work Board for the highest ticket assigned to you
  2. Creates a new local git branch inferred from ticket name and prefixed with your github prefix
    (It is always forked from master and ensures master is up to date)
  3. Moves the card to Doing
  4. Opens the card in browser for review

Issuing Pull Request[source]


bb gh pr [CARD_URL]

See threading for more details.

Checking Dependencies


Code review

Code review ensures the quality of the code and disperses the knowledge about the code and features through the team., branch)[source]


bb gh status
bb gh status my_branch_name

Applicable for PRs and branches
blackbelt.handle_github.check_status(pr_url=None, branch_name=None, error_on_failure=False)[source]

Returns status and required checks status of a given PR or branch.

This can be used to determine if a PR/branch can be merged without issues. Required checks might involve a status of a CI build, status of code reviews, etc. (see

Pull requests

  1. Checks for Pull Request current state (open/closed)
  2. Retrieves required checks status (success/failure/pending)


  1. Retrieves required checks status (success/failure/pending)

Merging Pull Request[source]


bb gh merge

This merges PR on Github into master:

  1. Inspects the current repository and the pull request
  2. Switches to master and brings it up to date
  3. Merges the PR locally and pushes to master
  4. Deletes the merged branch from the remote repository/github


  • Comment the associated Trello card

Deploying Pull Requests[source]


bb gh deploy

Deploys PR to production

  1. Does Merging Pull Request
  2. Inform people on Slack about the merge and the deployment intent
  3. Prepares Heroku deploy slugs using grunt create-slug
  4. Waits for CircleCI tests to pass
  5. TODO: If they fail, asks for retry
  6. Asks for deploy confirmation
  7. Notify others on Slack about deploy
  8. Deploys
  9. Creates a release on GitHub, using merged branch name as ‘ref’.
  10. If it can figure out related Trello card (looks for “Pull request for <link>”), moves it to “Deployed by” column
  11. Does not bring beer yet, unfortunately

Deploying master

Deploy current branch to production with:

bb production


  1. Informs others on Slack
  2. Deploys master to production using grunt deploy
  3. Deploys master to production using grunt deploy --app=apiary-staging-qa
  4. Deploys master to production using grunt deploy --app=apiary-staging-pre

Rollback production

Rollback production to previous version with:

bb rollback


  1. Informs others on Slack
  2. Rollback production using grunt rollback
  3. Rollback staging-qa using grunt rollback --app=apiary-staging-qa
  4. Rollback staging-pre using grunt rollback --app=apiary-staging-pre


Deploy current branch to staging with:

bb stage


  1. Discovers what the current branch is
  2. Informs others on Slack
  3. Deploys the branch to staging using grunt deploy