No doubt, running multiple environments for apps provides immense benefits and helps dev teams to be a lot more productive and efficient. Some of the popular benefits are that it empowers parallel development efforts and protects company profits and revenue by ensuring reliable and dependable software with minimal downtime.
That said, teams often run a combination of some or all of these environments for their apps;
- Development environment
- Test environment
Until recently, our team used to run Dev > Staging > Prod. About a couple of weeks ago, we commenced running a ‘test environment’ in addition to the existing configuration using Heroku’s review apps.
Heroku is a cloud-based platform as a service (PaaS) that enables developers to build, run, and operate applications seamlessly. Heroku offers several products and solutions but we were particularly interested in using it to achieve efficient continuous delivery.
Heroku review apps are instant, disposable app environments that are spun up automatically with each GitHub pull request or manually created from your app’s pipeline page on the Heroku Dashboard. We went for the former which means that upon a successful GitHub pull request, a review app is created having a unique URL which grants QA (me) the opportunity to test features before the pull request is merged into the staging branch. This unique URL/review app is deleted as soon as the pull request is merged or closed.
Why we chose to run Test environment(review apps) in addition to Staging
- Quicker turn-around time for quick/small bug fixes and features: Running a test environment grants us the opportunity to review and provide relevant feedback on small features, fix issues raised, stage and promote to production swiftly. All these are done without being delayed by external dependencies that only relate to other complex features.
- Long-term/Complex features can be tested patiently and thoroughly in isolation: With the previously mentioned point, we can patiently and thoroughly test complex features on the review apps (temp test environment) which has the same configurations as our staging or production apps. Also, completed features that are still awaiting a go-ahead from the management team can be left unstaged.
- A more reliable staging environment: Because we only merge feature branches into the staging environment when they have been reviewed and certified, we can now boast of a more reliable staging environment that can be used for demos and end-to-end tests with other teams. This is particularly beneficial to companies with multiple dev teams working on a robust solution.
Challenges faced so far.
It has only been a couple of months since we started using Heroku. For now, here are the challenges we have faced.
- Issuing SSL certificates for review apps with our domain structure: Our app currently runs a domain structure such that on prod, we commission a sub-domain each for our many partners. This has therefore made it a bit difficult to automatically issue SSL certificates for review apps for the subdomains. We have come up with a workaround for this using a custom script that creates new subdomain in our domain provider (AWS route53). The script is run whenever a new review app is generated.
- Proper notification to Jira about deployment: So far, it’ has not been very obvious for us on how to get Heroku to spontaneously communicate with services like Jira to notify about deployment. The workaround we are working on is to name git branch with feature ID in it and in the post-release script to send an update to Jira.
Interested in knowing more about how Heroku can help you achieve an efficient workflow for continuous delivery using Heroku Pipelines, Review Apps, Heroku CI and GitHub integrations? You can check here.