Hacker News new | ask | show | jobs
by fhwang 5249 days ago
Yeah, personally I know a number of solid devs who like feature toggling but the notion has always rubbed me the wrong way. Especially because half the time I'm adding a non-trivial feature, I'm always semi-refactoring the code underneath to deal with the common patterns and concepts that emerge as a result of that addition. But I'm a big refactoring-as-you-go kind of person--I don't know how common this is.

Branching is definitely a significant investment for a team. It's best done when you've got somebody in-house who can guide everybody through the etiquette and how to use git to best support it. And if you want to do it all the way then you want to support in multiple places in your development stack -- QA servers, staging servers, CI, etc.

But for large units of work that genuinely should stay out of master -- large user-flow rewrites, big code refactorings or database migrations -- I find it a great way to have significant experimentation off to the side and then bring it back into master when it's ready for prime-time.
1 comments
sandGorgon 5249 days ago
this was a question I had - how do you have your QA,testing,staging setup to test branches ? Or is fast and frequent commits (by design) eliminate the need for the commit-deploy-test cycle and replace it with a review step instead ?
link
fhwang 5249 days ago
Generally speaking I like to have at least one CI environment available for every branch that makes you nervous, plus master. So what number you're dealing with depends on the team. Sometimes you have eight engineers but only four of them are doing something major at any given time.

Of course, whatever you call what you deploy to production -- master, production, timestamp tagging, etc -- it should ideally pass CI before getting deployed as well. And there are merge conflicts to deal with, too -- that ideally belongs to whoever's doing branching.

So, maybe my ideal workflow looks like this:

  * Branch away from master
  * As you work in your branch, grab a CI server if you feel like it (telling
    everyone else)
  * Commit code in your branch, keeping an eye on your CI as you go
  * Periodically merge in from master, dealing with merge conflicts in your branch,
    *not* in master
  * When you feel like it's ready to go, get whatever review you feel like you
    need -- code review, product manager review, etc
  * If you feel 99% certain it's good, merge it into master and push that back to
    origin
  * Wait for master CI to pass
  * Deploy to production
  * Beer
From an etiquette point of view, there are things that can go wrong, not least the individual commitment to deal with merge conflicts before they get involved in master. And conflict resolution cannot be rushed. If you have engineers who are just gonna edit files randomly to get git to accept their merge, you're going to have problems. (But if you have those sorts of engineers, you already have problems.)
link