DEV Community

Discussion on: Agile Git Integration with GitWorkflows

Collapse
 
cristinaruth profile image
Cristina Ruth

I remember having this problem a few years ago. Business people changed their minds frequently also. It was a pain.

As a result, we implemented feature toggles. It also helps keep a feature stable and can easily turn it on or off depending on bugs found or the feature readiness. Is that something you guys have tried and just didn't work out?

Thread Thread
 
integerman profile image
Matt Eland

Feature toggles are interesting and I've written on them before.

My primary concern with using feature toggles as a way of saying "we don't want this now" is that it is often additional dev work you didn't do originally, it's additional strain on configuration teams if devs don't have access to production configurations, in testing you really have to test features off, on, and moving between the two.

Additionally, features with database dependencies or other architectural dependencies can impact other features in ways you might not test.

My general policy is that I don't want any set of code changes going out unless it's tested, and if a feature needed to be pulled because of bugs, there's not necessarily a guarantee that bugs won't be present in layers not directly tied to the feature's UI.

That said, I've used feature toggles in a few pinches with good effect under a new work item to disable other work items on a temporary basis - you just need to understand the full impact of the flag and test it appropriately.

Thread Thread
 
cristinaruth profile image
Cristina Ruth

Oh definitely. They come with overhead themselves. You gotta use them properly.

Using feature toggles does not mean testing goes out the door. You still want to test things before they merge to master. I personally deploy feature branches to test them first before I merge them to master. But we can't test and foresee all problems so it's hard to completely test before merging.