It’s no surprise that the number one reason for startups failing is not solving an existing market problem. Identifying real users’ pains is crucial when creating a new produ...
How to streamline development on Heroku with review apps and pipelines
Heroku is an extremely useful platform for deploying all kinds of web applications. Node.js, Ruby, Java or Python are only a few notable technologies that can be set up on Heroku in just a few minutes. Although it could seem like focusing on simple processes restricts us from building more complex deployment structures, few people know about some useful Heroku features, targeted for advanced app pipelines.
Connecting Github and Dropbox
After setting up a new application on Heroku, the service provides Git remote URLs for easy deployment. This part is rather clear to everyone who has used this kind of service even once. In this case, on our local machine, we can have “remotes” pointing to remote Git repositories (for example in Github or Gitlab) and separate ones for Heroku. Only one push is enough to start the building process of a new version of our service.
In its history, Heroku has always tried to make this process even simpler. Probably even a bit too much. One of the interesting features was connecting to a Dropbox folder and doing deployments even without using Git. So for the end-user, the process would only require syncing a local folder to Dropbox. After each save, Heroku would start a new deployment.
It might have been useful for beginners who didn’t want to embrace a simple version of a control mechanism like Git but it had some inherent problems. As developers prepare updates in the app, commits are often used as marking points for “working” stages of the application. And between these points... well, crashes were more than expected.
Heroku then had to build a lot of versions of apps that were broken, and in some rare cases, could also alter databases in a way that was not intended, making the development process quite the nightmare. As cons clearly outweighed the pros, Heroku announced that it will be discontinuing this feature.
Although Dropbox might not be ideal for a one-off app deployment setup, Github is a whole different story. Instead of pushing each version to Heroku manually, users can base deployments on Github webhooks.
To save some time, after opening app details in Heroku, in the “Deployment” tab, we can select a “Deployment method” and point to the correct repository stored in Github.
After finding the correct repository, a new section should appear at the bottom. This part is even more important, as we need to decide which branch of the repository should be automatically deployed to the server. Depending on the local setup and methodology, it’s usually advised to have a separate “production” branch set, if we expect to deploy only non-breaking changes.
Additionally, there's a possibility to enable the “Wait for CI” feature. In this case, after building the application, Heroku will try to run continuous integration tests and deploy a new version only after all specs are “green”. For this step, we can use external services like CircleCI or the service built-in into Heroku (and charged extra but easier to set up) called Heroku CI.
We’ve learned how to automatically deploy one application to Heroku but these days, as cloud services are easily accessible and affordable, no one is basing development around just one server. New features are usually deployed into the “master” branch but I’ve already mentioned the “production” version of the app for end-users, which is not expected to misbehave.
Depending on the application’s scale, it’s not rare to encounter even more “stages” of development which would be useful to have. The most common one is the “pre-production” phase, which closely mirrors the “production” environment. Even after testing on staging, the ability to review everything on pre-production with a production-replicated database and plugins can be quite beneficial.
To solve complicated relations between multiple environments, Heroku prepared Pipelines. A Pipeline can be created from the top right corner menu (same as a new application) with the button “Create New Pipeline”. In this case, we only need to select the correct Github repository. The main downside is that only Github is supported, so GitLab or BitBucket, which have recently gained huge momentum, are left out of the mix.
Pipelines allow for neat organization and easy promotion between different branches. They are especially useful when using Review Apps that I’ll describe in more detail in the following section.
We already have multiple environments but there’s one phase that we missed — Pull Requests. Even though the “master” branch is prone to breaking in most cases, we can still deploy a test branch into Heroku before merging new code. The only problem here is that no one wants to waste time on setting up a new application for each new branch.
This is where Review Apps come in. They allow for the automatic creation of apps when a new Pull Request is prepared. We can enable this feature easily on the Pipelines view by clicking on the “Enable Review Apps” button.
In the side panel, there are a few additional options:
Create new review apps for new pull requests automatically. This is must-have for the pipeline. New apps will be set up just seconds after PR is ready, and they will be exposed to a new domain, so service can be shared with the QA team. Even before testers jump into the new code, it’s useful to check if a new version is correctly built and works on the server in the same way as on a local machine.
Wait for CI to pass. Same as with automatic deployment of standard applications, if time is not an issue, it's a good idea to wait for the tests to be run before we even start testing.
Destroy stale review apps automatically. This is crucial, as the number of branches grows, review apps will pile up quickly. Enabling this function will clear old ones automatically, so they won’t be using up Heroku’s resources after they are merged into the main branch.
How much time is saved with Heroku?
It’s clear now that Heroku outgrew small applications a long time ago and it’s not only a tool for hobbyists. With pipelines and review apps, it’s quite easy to prepare a development structure containing multiple environments, automatic deployments and a pre-merging stage for quality assurance.
For companies, the most important question is: how much time (and money) is saved by this structure. Fortunately, the answer is quite straightforward. Setting up a similar deployment process on Amazon Web Services, Google Cloud Platform or dedicated servers would without a doubt require at least threefold the time and a more experienced person to do the job.
On the other hand, there are also some downsides. The structure provided by Heroku is fixed but also closed. We can’t really tweak any additional parameters or create custom steps, like static code analysis. This would have to be done on external services and be integrated at the level of continuous integration.
With millions of different applications, it’s impossible to come up with an infrastructure solution that would be perfect for all of them. At the expense of customization, Heroku is aiming to provide tools that would cover most common cases, at least in early phases of development and for these apps, it’s hard to find a better solution.
You may also like...
Innovation never happens alone. Synchronized teams create the best products, and the most effective way to teamwork is, of course, through workshops. We're following these guidelines...