Github Workflow & "Feature Toggles"
I'm working with git & github as a vcs for the last 3 years. It's a great concept, and github has supplied great tools for developement workflow and keeping the development process documented in a well user interface system.
Recently, I was introduced to the concept of "Feature Toggles" in software developement.
The demand from the development team was to start supporting in "feature toggles" while developing, and push all code to the master branch - while having no spereate branches - known as - feature branches. That, in order to support Continuous Integration, Automation Tests often and avoiding complicated merge.
As a background, "Feature Toggles" (or "feature bits") means, that each feature in the application is configurable and can be turned on or off in any time without causing errors on all development layers - let it be ui, server and data base. Practicaly, during the development cycle of a feature, it is in an "off" mode, untill all relevant layers are developed and are ready to introduce the feature. Meantime, all code relevant to this feature is pushed to the "master" branch, but not "active" in ui or server.
the pros for that are (as given):
- it promotes CI.
- allows testing earlier
- prevents complicated merge flow / conflicts
- business oriented - allows to toggle features based on user roles, permissions or customer regulations (that's a business perspective, though)
This is a good example of implementing "feature toggles" with angular.
The idea of not using feature branches and having only one branch to work on led me to confusion.
I wanted to find out if using "Feature Toggles" is a common practice nowadays and whether it contradicts with "feature branch".
- what happens with the history of a feature?
- how do I group several commits under a feature development cycle?
- what if I want to remove this feature from the code?
So - I was glad to find out that the concept of "Feature Toggles" doesn't contradicts with developing iwth feature branches.
On the contrary, the two concepts works well together, and even - should.
I have found out few advantages of using the github workflow:
- promotes safer deployable master branch
- promoting code-reviews/testing etc before merging to master
- promotes CI
- visibility of work to the team
- you can use Hubot - also for FUN :), deploy process becomes easier for all
Having the above approach to go with "feature branch" led me to wonder what to do with branches that were merged to master.
Since the content and author of the code is preserved, it is safe and preffered to delete these branches (if there's no other use for them). And still, it is clear what are the active branches and who's working on them just by viewing teh branches.
Another approach combines some of the above:
- Work with a Branch model (feature/ hotfix/ bug/ chore/)
- CI works on all branches with Pull Requests
- Once code is in master you can use any type of feature flag you want. "rollout" can be used, which is a redis based feature rollout system.
- Any branch can be deployed to any environment and not just master, meaning you can deploy a specific feature branch for any amount of time you may want.
To conclude, having Scott's approach seems to win the case for my dilema - It is resonable, takes into an account team work, promotes discussion while saving a certain protocol, and eventually allows Continous Integration & Delivery.