CODEWITHSUNDEEP
githerokuplayframeworksynchronizationplayframework-2.0
Peter Warbo
Peter Warbo

Reputation: 11700

Heroku differentiate between production and staging app

I'm creating a Play 2.1.3 web app and I have setup two environments in Heroku, one for production and one for staging.

What is the easiest way to differentiate between the two environments? For instance I don't want the search robots to index my staging app so I want to add a robots.txt for staging but then it will also be added for production when pushing the repo.

Should I have two local (app-prod and app-staging) Play applications with separate git repos on my computer? Then I will have to keep the two applications in sync. After verifying that the staging app on Heroku works successfully I would have to sync those changes with my production app locally on my computer (how do I do that with Git?) and then push those changes to the production app on Heroku.

Upvotes: 1

Views: 1194

Answers (2)

Jason Pearson
Jason Pearson

Reputation: 619

You could make a route called robots.txt that either returns a 404 or the actual asset. It could look at application.conf which in turn would read from environment variables that you would set for your different environments to modify app behavior.

Edit:

I should have explained my solution better. You can create a controller to have some minor logic. This is where the logic for returning a 404 or the actual robots.txt file should be given.

package controllers

import java.io.File
import play.api.mvc._

object Robots {

  def get = Action {
    Ok.sendFile(
      content = new File("/path/to/your/robots.txt"),
      fileName = _ => "robots.txt"
    )
  }
}

You can find the documentation on serving files here: http://www.playframework.com/documentation/2.2.x/ScalaStream

And then the routes file would just have

GET /robots.txt   controllers.Robots.get

This would have higher priority than the assets controller

Upvotes: 1

John Beynon
John Beynon

Reputation: 37507

I'm not familiar with Play but for my applications I use a basic authentication prompt on them for staging so I know that nothing can be seen whilst I'm working on it or indexed at all.

If you want to use a more traditional git flow your are best with having two Heroku applications and deploy to them from a single git repo using corresponding branches - when you connect your repo to Heroku then name the remotes something like production and staging so it's easier to distinguish when you push. (you would probably be used to see git push heroku master up to this point)

eg

git remote add production <git url of production heroku app>
git remote add staging <git url of staging heroku app>

then your deployment process becomes;

  • git push staging staging:master - deploy local staging branch to the staging remotes master branch
  • verify on staging Heroku app
  • git checkout master - switch to local master branch
  • git merge staging - merge staging into local master
  • git push production master - deploy local master to the production remote

Heroku have also introduced a new feature recently called Pipelines which sounds like it might be of also be a fit here https://devcenter.heroku.com/articles/labs-pipelines.

Upvotes: 1

Related Questions