DEV Community: Maximilien Pressensé

Heroku Review Apps: setup & configuration

Maximilien Pressensé — Fri, 23 Oct 2020 11:20:42 +0000

At my job at VideoRunRun, we use Github and Heroku.

We have a pipeline with a staging and a prod app, and when I joined the team few months ago, I suggested to enable Review Apps as well.

What are Review Apps ?

I'll quote the official documentation:

Review apps run the code in any GitHub pull request in a
complete, disposable Heroku app. Review apps each have a
unique URL you can share, making them a great way to
propose, test, and merge changes to your code base.

Mainly, it allows us to shorten feedback loops, especially with our Product Owner, for UI/UX considerations, for testing purposes in a production environment, for PR reviews, etc.

Overall it's very convenient for many different use cases and we just love it.

It's a killer feature.

Setting it up

In order to use Review Apps up to their potential, they must be ready-to-use as soon as they are deployed.

If you need to manually set up heroku dependencies, define some env vars, or run a script every time you need to use a review, poor child you're lost.

As always, automation is key.

Luckily, Review Apps are very easy to set up and documentation is pretty straight-forward.

General config happens on Heroku UI:

There you can enable Review Apps, define env vars, choose a URL pattern, etc.

For advanced config, you'll need to add an app.json file to your app's root folder.

Here's a working example:

# app.json
{
  "environments": {
    "review": {
      "formation": {
        "worker": {
          "quantity": 1,
          "size": "free"
        }
      },
      "addons": [
        "heroku-postgresql:hobby-dev",
        "heroku-redis:hobby-dev"
      ],
      "scripts": {
        "postdeploy": "rails db:schema:load db:seed"
      }
  }
}

Populate your database

If your seeding scripts aren't giving you all the data you need, you might lurk at your sexy staging database.

Here's what Heroku's team has to say about it:

Looks like you'll have to work on that seeding then.

You don't want to ? Tell me your reasons in comments please.

Anyway I've got you covered.

One could simply use his staging database both for reviews and staging environment. (bad solution imho)
One could hack his way around :

# app.json
{
  "environments": {
    "review": {
      "buildpacks": [
        {
          "url": "https://github.com/heroku/heroku-buildpack-cli"
        },
        ...
      ],
      "scripts": {
        "postdeploy": "heroku pg:copy {STAGING_APP_NAME}::DATABASE DATABASE --app $HEROKU_APP_NAME --confirm $HEROKU_APP_NAME  && sleep 1s && rails db:migrate"
      }
    }
  }
}

It consists on installing Heroku CLI directly on every app reviews. Then the postdeploy script launchs the appropriate heroku command and runs migrations. Beware you'll need to set HEROKU_API_KEY first. RTFM !

References:

official documentation for heroku reviews (https://devcenter.heroku.com/articles/github-integration-review-apps)
official documentation on app.json (https://devcenter.heroku.com/articles/app-json-schema)
official documentation about buildpacks (https://devcenter.heroku.com/articles/app-json-schema#buildpacks)
heroku buildpack-cli (https://elements.heroku.com/buildpacks/heroku/heroku-buildpack-cli)
official documentation about heroku database handling (https://devcenter.heroku.com/articles/heroku-postgres-backups#direct-database-to-database-copies)

Rails: minitest & GitLab CI

Maximilien Pressensé — Fri, 09 Oct 2020 15:44:13 +0000

Hi everybody, this post is the first of a serie I'd like to write, revolving around rails and CI/CD.

In this one I'll show you how to setup a proper CI for your new rails project.

I tried to give you the simplest example in order to focus on what's interesting, the configuration, I hope you'll find it useful.

Here is the repo alongside this article: https://gitlab.com/mpressen/rails_with_gitlab_ci

Init project

$ rails new rails_with_gitlab_ci --database=postgresql
$ cd rail_with_gitlab_ci
$ rails db:create db:migrate
$ rails server

Perfect time to commit and push our code :

$ git add -A
$ git commit -m 'init rails project with postgresql'
$ git remote add origin git@gitlab.com:$(username)/rails_with_gitlab_ci.git
$ git push --set-upstream origin master

Add failing tests

Let's create a failing controller test :

# test/controllers/dummy_controller_test.rb

require 'test_helper'

class DummyControllerTest < ActionDispatch::IntegrationTest
  test "the truth" do
    assert false
  end
end

And a failing system test :

# test/system/dummy_system_test.rb

require 'application_system_test_case'

class DummySystemTest < ApplicationSystemTestCase
  test 'the truth' do
    assert false
  end
end

Setup gitlab CI

# .gitlab-ci.yml

image: ruby

stages:
  - test

tests:
  stage: test
  services:
  - postgres
  - name: selenium/standalone-chrome
    alias: chrome
  cache:
    paths:
      - apt-cache
      - node_modules
      - vendor/bundle
  variables:
      DB_HOST: postgres
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: root
      SELENIUM_REMOTE_URL: http://chrome:4444/wd/hub
      RAILS_ENV: test
      BUNDLE_PATH: vendor/bundle
  before_script:
    - export APT_CACHE_DIR=`pwd`/apt-cache && mkdir -pv $APT_CACHE_DIR
    - curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
    - echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
    - apt-get update -qq && apt-get -o dir::cache::archives="$APT_CACHE_DIR" install -yqq yarn
    - yarn install
    - bundle install
    - bundle exec rails db:setup
  script:
    - bundle exec rails test  test/*

# config/database.yml

...
#
default: &default
  ...
  host: <%= ENV["DB_HOST"] %>
  username: <%= ENV["POSTGRES_USER"] %>
  password: <%= ENV["POSTGRES_PASSWORD"] %>
...

This config caches back and front dependencies for speed and computation cost (a must).

My favorite part is the use of a third docker image, selenium/standalone-chrome that avoids a pain point (chrome versions ...) some might have encountered before. With this config, it's another container that runs an headless chrome navigator on system tests.

# test/application_system_test_case.rb

require "test_helper"

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  if ENV['SELENIUM_REMOTE_URL']
    Capybara.server_host = '0.0.0.0'
    driven_by :selenium, using: :headless_chrome, screen_size: [800, 800], options: { url: ENV['SELENIUM_REMOTE_URL'] }
  else
    driven_by :selenium, using: :chrome, screen_size: [1400, 1400]
  end

  def setup
    if ENV['SELENIUM_REMOTE_URL']
      net = Socket.ip_address_list.detect(&:ipv4_private?)
      ip = net.nil? ? 'localhost' : net.ip_address
      Capybara.app_host = "http://#{ip}"
    end
    super
  end
end

group :test do
  ...
  gem 'webdrivers', require: !ENV['SELENIUM_REMOTE_URL']
end

Let's try it !

$ git add -A
$ git commit -m 'setup gitlab CI'
$ git push

Now, let's replace assert false by assert true in our dummy tests, commit and push.

Yeah !