Abstract Feature BranchAndy Maleh - Senior Agile Consultant

Outline● Problem● Solution● Code● Advanced Features● Alternatives● Q & A

Problem● Developer merged into master functional

code for an unreleased feature. ● Manager pulls developer off of feature just

prior to release to work on emergency fix● What does Developer do with merged code?

Problem● Alternative 1 - Delete code and re-add later

○ PURE INSANITY!!!● Alternative 2 - Comment code out in place

○ Results in dead code that might be way out of date and non-functional once enabled again

● Alternative 3 - Move code to a feature branch○ Expensive and can cost the team a lot more in

merging back later on○ Loses the team any benefits in code design

improvements that came from feature

SolutionBranch By Abstraction using Ruby gem: github.com/AndyObtiva/abstract_feature_branch

“A lesser-known source-control best practice I’ve been pushing for a number of years is “Branch by Abstraction”. It is not my invention, and has been best practice for many years, but how about it is given a name. The suggestion is that you can convene large sets of developers in a single trunk (Trunk Based Development) and avoid “short lived feature branches” that you have to merge back. The problem being with feature branches is that the current state of any one of them might be unable to be deployed for a number of weeks while the team gets it right. Those branches just end up running and running ….”

- Paul Hammant

Solution features.ymldefaults: &defaults

feature_auto_signup: true

feature_approve_network: true

feature_follow: false

feature_upcoming: per_user

staging:

<<: *defaults

feature_auto_signup: false

production:

<<: *defaults

feature_auto_signup: false

Solution Code - Declarative

feature_branch :feature_auto_signup do # perform logicend

Solution Code - Imperative

if feature_enabled?(:feature_auto_signup) # perform logicelse # perform alternate logicend

Run-time En/Disable● Enabling a new feature at run-time with environment variables:

ENV['ABSTRACT_FEATURE_BRANCH_FEATURE_AUTO_SIGNUP']='true'

● Disabling a buggy recently deployed feature without a redeploy:

ENV['ABSTRACT_FEATURE_BRANCH_FEATURE_AUTO_SIGNUP']='false'

Heroku● Enabling a new feature at run-time without a redeploy:

heroku config:add ABSTRACT_FEATURE_BRANCH_FEATURE_AUTO_SIGNUP=true -a heroku_application_name

● Disabling a buggy recently deployed feature without a redeploy:

heroku config:add ABSTRACT_FEATURE_BRANCH_FEATURE_AUTO_SIGNUP=false -a heroku_application_name

Per User Feature Enablement● AbstractFeatureBranch allows enabling

features per user● Users can be configured in a Redis table● That allows runtime enablement of features

for users

Summary of Benefits● Ensure integration of upcoming features into

the main code base to avoid major integration issues and delays down the road

● Avoid managing an unwieldy number of Git/Hg feature branches

● Toggle features at Run-time or deploy-time based on business needs, including web routes, CSS, and JS includes if needed.

Recommendation● To keep the code-base clean, have an

expiration policy to pluck out feature declarations after 2 months of each feature release (except when Business knows they want to delay a feature till later)

● In web apps, make sure to wrap routes declarations with abstract feature branching logic too for security purposes

Alternatives ● Ruby gems like Flipper or Rollout

○ Do not support simple config via yaml files○ Might be overkill for smaller projects○ Quite useful for bigger ones, albeit solving a different

problem (gradual roll-out, a/b testing, and multivariate testing)

● Actual Feature Branching (e.g., via Git)○ Simpler when the scope of change is contained

within 1 or 2 weeks of work only

Review● Problem● Solution● Code● Advanced Features● Alternatives● Q & A

More InfoGitHub: https://github.com/AndyObtiva/abstract_feature_branch

Contact:https://ca.linkedin.com/in/andymaleh