Best practices for Ruby on Rails *feature* deployment? [closed]
Asked Answered
S

3

2

We run 2 different environments on our server - say, production.mydomain.com and staging.mydomain.com

The staging environment is nearly identical to the production environment, except that it often has several new features which are being reviewed (eg new_user_profile, image_tagging, etc). These features are individually accepted by the client at different times.

What is the best way to push any individual feature (eg new_user_profile) from staging to production?

Our setup is listed below, but would like to hear alternatives you use also:

  • Ruby on Rails
  • Git (we have several feature branches, which get merged into a "staging" branch when nearing completion)
  • Capistrano, with multi-staging ext.

We have tried the following two approaches, neither of which works terribly well:

  1. Having lots of if/else statements throughout our code, eg if new_user_profile ....
  2. Deploying individual git branches (eg branch new_user_profile) to staging, getting this reviewed, and then merging to production
Symphysis answered 21/3, 2012 at 6:23 Comment(0)
P
2

Without additional ifs, your best bet would probably be to merge feature branches into master when they're ready to deploy. Alternatively, you could implement a feature toggle pattern. I don't know that there's a common gem for it, but I've used a similar pattern in my own projects. Martin Fowler wrote a good post on feature toggles here if you want to check it out. He makes a pretty valid argument that feature branches go against ideas of continuous integration. I don't feel so strongly about that, so long as the branches are being run through a CI server, but your milage may vary. I'd like to see a good library that just uses blocks with a feature toggle, so you could do something like:

with_feature :something do
  #code that should only be enabled with :something feature
end

Dont know of a well implemented solution for that though. Make a gem and put it on github :)

Praiseworthy answered 21/3, 2012 at 7:18 Comment(2)
The guys from learnable.com have released a gem for feature flipping which we use, based on how Etsy do it: github.com/pda/flipGomorrah
Thanks, the flip gem looks good and the Martin Fowler article was helpful.Symphysis
Q
5

Use this workflow:

  1. Use master branch as production branch, which always passes tests and deployable
  2. Use branch per feature and Pull Requests on GitHub or Merge Requests on Gitlab
  3. Use CI service (https://travis-ci.org/, https://circleci.com/) to check new branch code before merging
  4. Use special service for stages like http://teatro.io/ which will create parallel stage automatically for every feature branch. Send link for feature-stage to client.
  5. Merge branch tested by CI and cutsomer to master and deploy to production
Quartered answered 25/6, 2014 at 19:52 Comment(0)
P
2

Without additional ifs, your best bet would probably be to merge feature branches into master when they're ready to deploy. Alternatively, you could implement a feature toggle pattern. I don't know that there's a common gem for it, but I've used a similar pattern in my own projects. Martin Fowler wrote a good post on feature toggles here if you want to check it out. He makes a pretty valid argument that feature branches go against ideas of continuous integration. I don't feel so strongly about that, so long as the branches are being run through a CI server, but your milage may vary. I'd like to see a good library that just uses blocks with a feature toggle, so you could do something like:

with_feature :something do
  #code that should only be enabled with :something feature
end

Dont know of a well implemented solution for that though. Make a gem and put it on github :)

Praiseworthy answered 21/3, 2012 at 7:18 Comment(2)
The guys from learnable.com have released a gem for feature flipping which we use, based on how Etsy do it: github.com/pda/flipGomorrah
Thanks, the flip gem looks good and the Martin Fowler article was helpful.Symphysis
S
1

I think you should keep every new feature in own branches. At first time you can merge it with staging after testing merge with master.

Another way you can try git cherry-pick for move commits belongs to new_user_profile from staging to master

Sack answered 21/3, 2012 at 6:38 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.