gh-review-apps.md

Review and Test PR's on Heroku Review Apps

As the result of exploring Heroku review apps we came up with an experiment to run this sprint:

• We'll spin up review apps manually from PR's that you can find on sapling's deploy dashboard on Heroku
• Heroku has this name convention for the apps https://hipcamp-sapling-pr-1920.herokuapp.com
• Review apps will be destroy automatically once the PR has been merged
• Please don't leave review apps alive if not necessary, will pay for them by the second
• We should stop using slack bot to deploy to sapling or sapling and run this experiment
• We should share the URL on Trello cards. I'm going to look into the bot and see if I can add them automatically
• We could potentially change the process, read bellow if interested

Things to consider:

• HC-TRAIL is our new Heroku pipeline
• Hipcamp-sapling is set as the staging app for the the staging stage on the pipeline
• Hipcamp-sapling can be set to get the new code when merged to master, but currently this process has to be run manually
• Review apps can take up to 10 minutes to build
• Review apps use sapling's postgres database, redis and elasticsearch instances

How to use

• Go to hipcamp-trail dashboard
• Enable github on your account. It will be prompt if you can't see any PR on the review apps section of the dashboard (make sure there are PR's open in the repo)
• From the PR's cards on the review apps sections you can create, destroy, rebuild, check logs

Notes:

• sapling needs to be updated manually
• some env vars are inherit from sapling other are overwritten via config/staging.rb
• apps have a life span of one day
• apps have to be created manually

Alternatives to manage data in review apps

1. Recommended by Heroku. Migrate every time and have seeds files to populate individual instances. We dont have seeds at the moment.
2. We could migrate, dump and restore on each review app. But we thought that it might be too time consuming, considering that just building the app takes ~10 minutes (measured only one time)
3. What we are doing now, sapling maintains data consistency by keeping its db up to date and migrating there first when necessary. Then the review apps connect to that instance.

Alternatives to manage env variables using app.json

1. Inherit form parent

  "env": {
    "ASSET_HOST": {
      "required": true
    }
  }

2. Hard code file

  "env": {
    "ASSET_HOST": {
      "required": true,
      "value": <hard code value>
    }
  }

3. Override env variables programatically using the Heroku Platform Api and inherit from parent (we could have a way to do this easily with some tools) PATCH /apps/{app_id_or_name}/config-vars

$ curl -n -X PATCH https://api.heroku.com/apps/$APP_ID_OR_NAME/config-vars \
  -d '{
  "FOO": "bar",
  "BAZ": "qux"
}' \
  -H "Content-Type: application/json" \
  -H "Accept: application/vnd.heroku+json; version=3"

Exploration

Definition

Review apps run the code in any GitHub pull request in a complete, disposable app on Heroku. Each review app has a unique URL you can share.

Cost, Dynos and add-ons used by review apps are charged in exactly the same way as for normal apps. Costs are pro-rated to the second and you’re only charged for the time that the review app exists (typically while the GitHub pull request is open). You can optionally try to specify free or low-cost add-on plans in your app.json if those plans are sufficient to run and test your app.

You can configure review apps to spin up automatically for each pull request, or create each manually at the push of a button from the Heroku Pipelines page of the connected repo.

Review apps can only be used in conjunction with Heroku Pipelines.

Heroku Pipelines

Recommended work flow for Heroku Pipelines:

1. A developer creates a pull request to make a change to the codebase.
2. Heroku automatically creates a review app for the pull request, allowing developers to test the change.
3. When the change is ready, it’s merged into the codebase’s master branch.
4. The master branch is automatically deployed to staging for further testing.
5. When it’s ready, the staging app is promoted to production, where the change is available to end users of the app.

Currently we go to production on step 4 not having a staging app to promote.

Possible steps

Changing current deployment process:

1. Add a pipeline to hipcamp-tinh
2. Add hipcamp-sapling as staging stage on the pipeline
3. Review apps will be created upon PR to master using sapling as base, manually from heroku deploy dashboard
4. On merges to master code gets deployed to hipcamp-sapling
5. Start promoting manually from staging to production or investigate if this step can be added to GitHub integration (I did not see that as an option)

Without changing current deployment process (currently set on heroku):

1. Create a pipeline only for hipcamp-sapling set as staging
2. Review apps gets created manually, with sapling as base from heroku deploy dashboard
3. DB_URL is inherited from sapling
4. Once PR are marged to master, hipcamp-tinh and hipcamp-sapling get the code

Warnings

• Copying full database contents from parent to Review apps (similar to heroku fork) is not currently supported. Copying production data to test apps means risk of data leaks or other programming mistakes operating on recent customer data. For those reasons, we instead recommend seeding databases comprehensively with non-production data using seed scripts run with the postdeploy command.
• Builds take around 10 minutes
• We are inheriting the DB url from the parent app in this case hc-sapling
• Check cost at the end of the sprint

I agree with @jon-eckstein. Leaving everything as it is, no formal pipeline, but using one staging app to use as parent can be convenient.