Professional Software Development Outsourcing
Not all companies have the luxury of owning an in-house tech team. That is to say, the luxury of having a skilled team they can consult when looking to achieve tech-related business goal...
Heroku is a handy 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 of some useful Heroku features, targeted for advanced app pipelines.
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 exciting 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 saves, 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 the "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 outweighed the pros, Heroku discontinued 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 the 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 critical, 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. 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 deploy one application to Heroku automatically, 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, reviewing everything on pre-production with a production-replicated database and plugins can be quite beneficial for application monitoring.
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 "Create New Pipeline" button. In this case, we only need to select the correct Github repository. The main downside is that only Github is supported so that GitLab or BitBucket, which have recently gained tremendous 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 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 a 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 that 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 automatically clear old ones, so they won't be using up Heroku's resources after merging into the main branch.
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 require at least three times 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 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 aims to provide tools that would cover most common cases, at least in the early phases of development, and for these apps, it's hard to find a better solution. Please let us know what you think. Send us a message or write to us at hello@start-up.house