GitHub integration, Auto Deploy and Review Apps

We're very happy to release today our deep GitHub integration, unleashing new capabilities of autodeployment when the code is hosted in a GitHub repository, deploying directly from a GitHub branch, automatic building and deployment of Pull Requests, and much more.

At Scalingo, our mission is to make developers' life easier. A lot of them are using GitHub as source code hosting platform. Fortunately, GitHub has particularly good interoperability capabilities that we've used to deliver a powerful and well integrated GitHub based workflow.

The GitHub flow

Like most team of developers on GitHub, we follow the GitHub flow to integrate new lines of code in our codebase. This workflow follows these rules:

• Anything in the master branch is always deployable
• Create a new branch based on master for each new feature or fix
• Commit your changes on this new branch and push the to the GitHub remote
• When you need feedback or help or you think the branch is ready for merging, open a pull request
• After someone else has reviewed and signed off the patch, you can merge it into master
• Once it is merged and pushed to 'master' on the origin, you can and should deploy immediately

Our deep GitHub integration aims at automating this workflow.

The GitHub Integration

The GitHub Integration is available in the 'code' section of your dashboard. It's composed of two mains parts: Auto deploy and Review apps.

To enable GitHub relative features on your Scalingo app, you have to link it to a GitHub repository. You can only link your app to a repository that you owned or which is owned by one of your organizations. Note: If it's an organization repository make sure that you have admin access on it.

Under the hood, we will add a webhook on your repository that will notify the Scalingo platform for each event generated in your repository lifecycle: like 'Push', 'New pull request', etc.

Auto Deploy

Once your app is linked, you can enable 'Auto deploy' from a given branch of your repository. It means that your app will be strongly linked to the selected branch, a new deployment of the application will be started each time the code of this branch is updated on GitHub.

You may have continuous integration tools associated to your repository like Codeship or TravisCI which run tasks, tests or whatever. We will always wait that all GitHub statuses succeeds before deploying your app.

Manual Deploy

The manual deploy feature lets you instantly deploy a branch from the GitHub repository linked to your Scalingo app. It can be useful to quickly deploy your app or in the case of you're not having access to a computer having a proper git installation and you edited code directly on GitHub.

Review Apps

Review apps are a powerful collaboration tool to discuss about a new features between members of your organization.

Let say that you have worked some hours on an awesome new feature. It's time to show the world your work and to open a new Pull Request (PR) on GitHub (even if it's non fully done). With review apps enabled on Scalingo, we will create new application, called a review app with the code of the new feature. You can now easily share the result of your work, to get it validated, with all people involved, even if they are not in the tech field.

Maybe they will tell you to change something like adding tests or to change a button color. You just have to push your modification on the branch involved in the PR to update the review app.

Once all of our teammates are satisfied and the PR is closed, we will automatically delete the review app. You can disable this behavior or add a delay to fit your needs. This latter setting means that you can still review PR after your dev team has closed the PR.

If you don't want to create a new review app for each PR you can also choose among open PRs of your app to manually deploy a review app.

What about Addons, collaborators and environment variables?

If you've enabled Review Apps, a new application will be created every time a new Pull Request is opened in your GitHub repository. This new application is a child application (we'll see later this year which new exciting stuff this link will help us build). This child app will have a copy of add-ons, collaborators and environment variables from the parent application.

Most of the time you want to customize those 3 things. That's where the new postdeploy hooks and manifest come in handy. Combining those two powerful features, you can tailor exactly how child apps are configured and their behaviors.

As a quick example, here is a sample scalingo.json that customize the environment variable CANONICAL_HOST_URL for a child app:

{
  "env": {
    "CANONICAL_HOST_URL": {
      "generator": "url"
    }
  }
}

Here, the value of this of the variable will contain the URL to reach the newly deployed app. The scalingo.json configuration always takes precedence on parent app configuration.

Conclusion and Future Improvements

A lot of people are seeing Scalingo as a hosting platform, meaning a platform hosting production services. Of course, we put a lot of energy into making Scalingo of production grade quality. With this new GitHub Integration feature, Scalingo becomes an even more powerful platform for developers. Linked to our recent Docker plugin announcement you can imagine all new kind of workflows tailored to your enterprise organization, preferences or constraints.

And if you're using Bitbucket or GitLab, don't worry, we're already thinking of integration with those services.