A related way to try to do this is with the use of feature branches. With that approach you would just keep all your features in a separate branch named like feature/my-new-feature and merge them with the main branch when ready. This potentially reduces the complexity of enabling and disabling the feature flags, but it also reduces your ability to run integration tests. And brace yourself for doing some complex code merges...
So this setup seems to me like a good fit for some situations. I also like your idea's with the more complex logic and would like to see that in future blog post. ;)
A disadvantage of only merging feature branches once ready is that the integration efforts (time needed, costs involved) rise exponentially. In other words, the longer you wait with integrating your feature branch, the harder and riskier it gets for a feature to get merged in the main branch.
And yes, you can regularly merge the main branch back in the feature branch, but that effort is identical to shipping code as often as possible (merging forward) and having a feature flag that is disabled in production. The overhead of coding the feature flag is definitely worth it, and will even allow business to do cool things like releasing features to a small set of testing customers.
In other words, the biggest perk of shipping disabled features that should not get underestimated, is that continuous shipping will give you continuous feedback on side effects and regressions. Knowledge that possibly would be harder to collect outside of a production environment.
The longer deployments of code to production gets postponed, the more likely that the engineer responsible of that code does not know the specifics about it anymore. And, that engineer even could have left the company already.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A related way to try to do this is with the use of feature branches. With that approach you would just keep all your features in a separate branch named like
feature/my-new-featureand merge them with the main branch when ready. This potentially reduces the complexity of enabling and disabling the feature flags, but it also reduces your ability to run integration tests. And brace yourself for doing some complex code merges...So this setup seems to me like a good fit for some situations. I also like your idea's with the more complex logic and would like to see that in future blog post. ;)
Fully agree! Maybe in more planned situations git branching is better, but as you said, in some situations this approach fits.
I put into my todo list the more complex logic for the next post 🤘
A disadvantage of only merging feature branches once ready is that the integration efforts (time needed, costs involved) rise exponentially. In other words, the longer you wait with integrating your feature branch, the harder and riskier it gets for a feature to get merged in the main branch.
And yes, you can regularly merge the main branch back in the feature branch, but that effort is identical to shipping code as often as possible (merging forward) and having a feature flag that is disabled in production. The overhead of coding the feature flag is definitely worth it, and will even allow business to do cool things like releasing features to a small set of testing customers.
In other words, the biggest perk of shipping disabled features that should not get underestimated, is that continuous shipping will give you continuous feedback on side effects and regressions. Knowledge that possibly would be harder to collect outside of a production environment.
The longer deployments of code to production gets postponed, the more likely that the engineer responsible of that code does not know the specifics about it anymore. And, that engineer even could have left the company already.