Feature Gates when developing new functionality in old software

[Thorin]

The team I'm on has been tasked with adding a new permission system into our application.  Since I'm the only developer on the team that will work on this, and the new permission system will touch basically all of the app, the work is expected to take quite a while.  We work in two-week sprints, and it will probably take twelve or more sprints to accomplish everything.  We also release our software roughly every two sprints (once a month).

So how do I add new code and deploy it every second sprint when it's not complete?  Feature Gate.  There's a setting in the config file, and if it's True then use the new code, but if it's False or missing then use the old code.

This allows me to deploy the new code to our team test environment, shared test environment, staging environment, and production environment, all without it actually being used.  When QA then wants to test it on our team test environment, they can simply switch the setting to True there, and test away.

I had also thought of making a new branch (fork) of the code to do my development on, but because it's expected to last so long I didn't like the possibility of lots of bug fix merging that might need to get done.  Plus, I'm the only dev working on the code.

[Mr. Analog]

Feature gate all the way.

Developing deep new features across sprints is hard no doubt, using a feature gate you can control development features throughout the application so they can be enabled when you are ready but still close stories per sprint.

My team runs into this from time to time and sometimes there have been whole new features deployed in the application to production that aren't enabled until they are fully tested and ready to roll.

So you have an "epic" story (you can represent this with an iteration path in TFS), then create stories that build the new feature piece by piece and keep it disabled until it's fully ready for implementation. In our team since we have a lot of stories being pushed forward we generally create a new branch for every new feature with the idea that the branch will be closed and merged back into Main by the end of the sprint (to avoid branch drift), with a feature gate you can easily integrate new features without enabling them, keep your branch development life cycle and not go crazy