DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
Assuming that feature flag toggles are a good idea, and should be implemented into code that developers write. For example Etsy swear by them as a major part of their culture.
What is a good way to persuade (and enforce) developers to start using feature flag toggles?
More information about feature flag toggles is explained in Q: How to use feature flag toggles, Q: What are feature flag toggles and very extensively in Pete Hodgson's article on the subject on Martin Fowler's blog.
Feature toggles are a common practice in high-velocity development because they de-couple development from release. Dev teams can "soft-release" a new feature to production, in a disabled state. This allows the feature to be released any time. If the feature is dependent on other work or preparation, it doesn't have to wait for a major release to go to production.
As far as "convincing" developers to use them, that's an exercise in making the case for the freedom it offers. My experience is that it's not a tough sell to developers. It's management that tends to be reluctant to try new things. Try this:
In an ideal world I think you roll out a new build and surprise! NOTHING changes. This is because all of your new features are behind switches that go out with the switch off.
Post-deployment you verify that your rolled-out service still works, the phones aren't ringing any more (unless ringing phones is your purpose, that is), etc. Once you are back to a known stable operation you begin enabling and verifying your newly deployed features.
Now for your answer: How would you like to work on a team where being on call is practically a no-brainer and our users love us because our sites and services are rock solid stable?
That's the team I want to work on.
You can stop reading here if you want.
Putting everything behind a feature switch seems like it can lead to spaghetti code everywhere. If you use IoC and are able to select between vNow/vNext/vPrevious then it comes down to maintaining your configuration. Yes more check ins, yes more classes (componentV1, componentV2, componentV3, etc.) but you actually have a more stable system? How? vNext is wonky? Switch back to vNow with your control tower. Been a week and vNow has a subtle bug? Same thing - go back to vPrevious just as easily.
No hassle, no worries, no lost sleep, no stress.
This isn't a pipe dream. I used to work there. Wish I could sell this to my current team.
A successful high-velocity development environment typically relies on a pretty strict automated system involving quality verifications with detection and rejection of faulty changes causing regressions.
Feature toggles offer the ability to commit even work-in-progress, untested changes without getting rejected for causing regressions in the integration branch. Which constitues a very good incentive to introduce the feature toggles very early in the life of the feature.
One of the disadvantages of deviating from true CI and moving feature development on feature branches is the lack of such incentive. Adding the feature toggle later on, when merging the feature branch into the integration branch is typically more difficult, like any late integration.
Developers (and usually development managers) usually look for two outcomes associated with framework: ease of management, and speed of deployment. You want to ship code faster, and easier.
Provide evidence that the approach works; try building a small POC using feature flags versus the old way. Case studies matter less to tactical people (developers\engineers) than strategic people (middle management\product designers).
The rationale to have feature toggles is not something for developers to decide. This is something for product owners to care. Developers enable this change in the most sustainable and safe manner. I critique this very question.
