Deploying to staging environments

Ruby on Rails
1

This isn’t actually specifically about Rails but I couldn’t find anywhere suitable put it.

I’m curious how ThoughtBot handles deploying to QA/staging branches so that a customer can review/approve a feature.

I’ve worked with two different approaches in the past in a team environment when doing branch-per-feature development:

  1. Have a pool of QA instances (e.g. virtualized on AWS). Provide a way a developer can be assigned a QA instance for a duration to deploy to, and then later release it back into the pool.
  2. Have a staging branch that everyone merges into.

I’ve found option 1 works well, but option 2 can end up in a mess due to conflicts (i.e. even if your branch can be cleanly merged into master, it may not cleanly merge into staging).

2 Likes
2

On most projects, we merge our changes to master after code review and then deploy master to staging (via git). Some projects set this up with continuous delivery hooking into CI, but the projects I have been on have not had automated staging deploys.

We try to keep master in a deployable state at all times. This works for most of our projects because we don’t have long release or maintenance branches.

This sounds like it could potentially give the client a view of something that isn’t entirely as it will be released. For instance, another developer might be working on a change that will have conflicting styles with the change you are working on and since you’re both using different instances to do acceptance against, you wouldn’t find out about the problem until too late.

For us, I guess that branch is just master.

3

@derekprior answered the question well. Our git protocol details our default branching strategy, which works very well for most projects much longer than people think.

We also aim to have our clients nearby, or able to run acceptance testing on our work as soon as its ready, as opposed to waiting for a QA team overseas or something to test something at night. In cases where we want to get product-level feedback from a teammate, we try to do that before code review, before pushing to a staging or feature environment. SSH tunneling tools such as ngrok are awesome for that use case. We just paste a URL into our project’s chat room that is publicly accessible but really running on our local machines.