Workflows


Please note this document refers to the new workflows available as of the December 2018 update of the Convox Console. Legacy workflows created prior to this update will still work, however they can no longer be created or edited. The new workflows provide much improved functionality over the legacy workflows and we highly encourage everyone to migrate to the new workflows.


Convox allows you to manage continuous integration and continuous delivery using workflows. You can use workflows to build automation such as deploying when you push to GitHub. You can create workflows by clicking on the workflow link in the navigation bar

Convox has two types of workflows:

Review Workflows

A review workflow allows you to review a new version of your application based on a pull request. When you define a review workflow for a connected Github or Gitlab repository, Convox will build your application whenever a pull request is created for that repository. If selected, Convox will also run your tests against that build and can even create a running review application so you can test your latest changes before you merge the pull request.

Creating a Review Workflow

Deployment Workflows

A deployment workflow is how you can manage the regular deployment of your applications to staging and production. A deployment workflow is triggered whenever code is merged into the specified repository/branch on either Github or Gitlab

Creating a Deployment Workflow

While deployment workflows are triggered by merges to the specified repository/branch you can also run a deployment workflow manually by clicking the play button

Workflow Jobs

Whenever a workflow is triggered it creates a job. You can view the jobs history by clicking on the jobs link in the navigation bar

Here you can see a complete history of all your review and deployment workflow jobs. You can also re-run any job. You can click on any job in the history list to review all steps and output from that job run.

Example Workflows

The flexibility of Convox workflows should meet the needs of almost any team but here are a few popular workflow examples:

Review Workflow for Testing

  1. Create a review workflow for your repository
  2. Assign the workflow to your staging rack
  3. Select “run tests” and “deploy demo”
  4. Specify any commands such as running migrations that you might need for your application to work
  5. Specify any specific environment variables you might need set or overridden for demo applications

Now whenever a developer on your team opens a pull request a demo application will be created and deployed in your staging rack. You can access the url for the demo application by going to racks, expanding the staging rack, and then clicking on the application name which should look something like “repository name - 1”.

A Gitflow Deployment Strategy

If your team practices Gitflow where you have a staging environment which is automatically built whenever a commit is made to your dev branch and you do production deploys by either merging your dev branch to your master branch, or by committing a hotfix directly to master, then you will want to do something like:

Staging Deployment

  1. Create a deployment workflow for your repository specifying your dev branch
  2. Add your staging application and choose automatic promotion
  3. Choose whether or not you want to run tests
  4. Add whatever before and after promotion commands you might need for staging

Production Deployment

  1. Create a deployment workflow for your repository specifying your master branch
  2. Add your production application and decide whether you want to promote automatically or manually
  3. Choose whether or not you want to run tests
  4. Add whatever before and after promotion commands you might need for production

Now whenever you merge to dev your staging application will be built and whenever you merge to master your production application will be built.

A Double Build Deployment Strategy

We are particularly fond of this strategy at Convox. With a double build, whenever code is merged into your master branch your staging application is automatically built and deployed and your production application is automatically built and ready to be deployed. With this strategy, once you are satisfied with your testing on staging all you need to do is click promote to move your code into production.

  1. Create a deployment workflow for your repository specifying your master branch
  2. Add your staging application and choose automatic promotion
  3. Choose whether or not you want to run tests
  4. Add whatever before and after promotion commands you might need for staging
  5. Add your production application and choose manual promotion
  6. Add whatever before and after promotion commands you might need for production

Now whenever your merge to master your staging application will be automatically built and your production application will be built and ready to promote. Once you are satisfied with your testing on staging you can click on your production rack, select your application, find the latest release and click promote.