We currently have two apps for the same website. The reason is that we want to have a staging environment. We also need a preview of our site to share with stakeholders before deploying. Our staging app currently facilitates both, which makes it a little complicated to manage merging of branches. It's common that code in staging make its way to our master by mistake. We have a guide, that if followed, prevent this from happening.

I see that Heroku have support for both preview, staging and deploy in one pipe-line instead of our two apps. But I am confused to how I would set it up to support our use-case.

Overview

I'm thinking that instead of having two apps, we should only have one with a better pipeline. But I'm unsure of how the preview feature works. Cost might also be an issue.

• We want a preview site for stakeholders on [stakeholder name].firefund.net or preview.firefund.net. We usually have multiple stakeholders at a time. We create a new git branch from master for each stakeholder. It is not important if stakeholders can see stuff from other stakeholders but we do not merge code from all stakeholders. Sometimes a branch will never get merged for various reasons depending on stakeholder.
• We need a staging area for general changes that we make to the website. We are the stakeholder for these changes, which are always purely technical and might break the website. We need to test our changes in an environment similar to production. staging.firefund.net is the URL for this. If everything works, we merge our feature branch to master and deploy on Heroku.
• We have a production site, which is always the code in the master branch.

Current Heroku setup

*PL: Pipeline

Example of git branches:

campaign/lbf           <- stakeholder branch
campaign/weresistburma <- stakeholder branch
feature/gulp           <- feature branch
feature/server-next    <- feature branch
master                 <- production site
staging                <- preview and staging branch

Question

How would a setup, that facilitates the wishes in "Overview", look like from a git and Heroku pipeline perspective?

It would be nice to create a campaign, push it to github and get a preview site to share with the stakeholder and iterate with until ready for going live. Without also having breaking changes in the mix.

And it would be nice to test code without having to know which campaigns are in preview and make sure they are updated locally so that the latest version can be merged and displayed on staging.firefund.net.

Edit

So this question has not gotten any answers and Heroku support only provided a link to https://devcenter.heroku.com/articles/pipelines. Even after reading the pipelines article (and many more), I still have some outstanding questions. Below I have added possible scenarios based on my current understanding, together with further questions about the particulars. I could be very wrong about how this works - corrections are greatly appreciated!

Scenario "new campaign"

Step 1-3 happens simultaneously for the 1-5 campaigns that we always have in our "pipeline".

1. We create a pull request (PR) from our master branch and push it to github.com
2. Heroku will detect github PR's and create a Review app with an URL like https://firefund-campaign-pr-77.herokuapp.com
   1. Our campaign branches follow a naming scheme and always start with campaign/[campaign name] - how do we tell Heroku to only create Review apps for PR's with that naming convention?
   2. And can we automatically customize the subdomain, e.g. https://firefund-weresistburma.herokuapp.com or setup subdomains via CloudFlare (that we use for DNS), e.g. https://preview-weresistburma.firefund.net? The predictable pattern screen shot does not show branch name.
3. We iterate over the design etc. with stakeholder and continuingly push new commits to the PR, which automatically updates the Heroku Preview app.
4. When the campaign is ready to be published, we promote it to staging.
   1. Can we merge multiple PRs into staging when we promote a Review apps?
   2. How does it work if we promote 4 campaigns (Review apps) to staging but only 3 of them will should be merged with master? Are they promotoed in parallel or merged?
   3. It strikes me that it would be easier for us to git merge a campaign, ready to go live, with staging and then run CI, merge it with master and then deploy on Heroku. Or perhaps skip staging all together and merge with master.

Scenario "new features"

This scenario must not conflict with the "new campaign" scenario.

1. We create a PR with the naming scheme feature/[name of feature].
2. This PR will not create an Review app, but we manually merge it with staging and access it at https://staging.firefund.net/
3. If everything looks good we can manually merge it with master and deploy on Heroku.

What I'm very unsure about is how these two scenario won't conflict and the promote functionality. Does it promote apps in parallel or merge branches? I think we will want to have the same database configuration for Preview apps and staging, so the staging stage might be redundant for Preview apps. Or am I missing something?

Can we configure at which stage(s) we want CI to run or is it running for all stages?

How do we manage costs? On https://www.heroku.com/pricing "Integrated CI/CD options", it says that "Heroku Review Apps" is included. Does that mean that Review apps created are free? We currently pay $7 per app. Which is not an issue as long as we can control our monthly expenses - e.i. limit monthly apps or similar. I'm worried that someone will create 30 campaign branches in a month and we do not realise until we get the bill. - we do not have any stable income