Feature Toggles & Trunk Based Development | How To and How NOT To

[@kgck15]

very neatly explained. Happy to have found this. I watched this and went around looking for other videos, later came back and watched this again, it all made so much sense. best content!.

[@Cognitive-Programmer]

Thank you so much for your kind words 🙏

[@miyazakizachary5108]

Great video. I have watched a lot of trunk-based development strategy and feature toggles/flags talks. This is by far the best and most concise explaining these ideas. Besides, your advice on feature toggles implementations is very useful. Thanks.

[@Cognitive-Programmer]

Thank you so much for your kind comment 🙏

[@PiyushGhosh-l4k]

How to implement feature toggles ? please tell , i'm confused !!!

[@z960849]

Good video. BTW I like this quote you made "Whatever things that gives us life, can take our lives too"

[@Cognitive-Programmer]

Thank you so much for your comments 🙏

[@ravishanker5877]

Very clearly explained in a very simple manner with clear and concise examples, but showcased a broader view of the main concepts.

[@Cognitive-Programmer]

Thanks for your comment 🙏

[@Anish-iw6ph]

Clear Explanation and Helpful.

[@Cognitive-Programmer]

Thanks for your comment 🙏

[@aayushiagarwal8063]

Thank you so much. Could you please explain how to plan releases with trunk based development. With a single branch, at what point of time we are saying we are good to go on production.

[@Cognitive-Programmer]

Thank for your comment, in general you can mark a point in the trunk, do all the testing and release, in the meantime people can continue working on the same. Hope it helps, Thank 🙏

[@ShreyaSharma-vg7eb]

Amazing explaination !!!

[@Cognitive-Programmer]

Thanks a lot for your comment 🙏

[@terencetcf]

I think what's really challenging is changes that are required data structure change. Meaning the object shape can be quite different before and after the change.

[@Cognitive-Programmer]

Thanks for your comment 🙏 Your assessment is correct, but here you can maintain a parallel feature version till it gets stabilises. There could be other ways also

[@benjaminmoseslieb9856]

I feel the same way, but after exploring feature toggles today, I like it more and more. I would be so nice to be able to toggle new or changed features on/off. I was imagining that you might need a toggle migration. The toggle migration would alter the database (rename fields and re-popluate duplicate fields) and swap the toggle flag.

[@QvsTheWorld]

​@@benjaminmoseslieb9856 I think ideally you might also want to implement partial/progressive releasing system for production so any breaking change would only affect a subset of your user base.

[@PiyushGhosh-l4k]

to achive this feature toggle , do we have to write terraform code ???

[@rangCRJ]

Please use a good mic for better voice recording. This can help the channel grow by making the content more accessible to all.

[@Cognitive-Programmer]

Thank you so much for your valuable feedback 🙏

[@dinobulja]

Hello, You replaced feature branches with branches you call "near-to-main" branches. I don't understand how that resolves issues with feature-branches. You still have to merge / integrate frequently. Are you saying while there are many "feature branches" you only have one "near-to-main" branch? Could you elaborate? Thanks

[@Cognitive-Programmer]

hi Feature branches are alive for a long time and at the same time changes continue to happen in the main branch. The idea behind near to main branch is the you check-in your codes to the main branch on a regular basis so that we can catch any issues early. Hope this helps

[@dinobulja]

@@Cognitive-Programmer Frequent merge/integration is a recommended way for feature branches so no they are not long living if you follow that plus long living feature branches are not recommended. So it is still the same. But mind answering my other question and thank you

[@Brajgamer]

​@@dinobuljaI think the major difference in feature based branching and this is that in the former approach we usually have dev QA uat branches and so on But by the time a feature travels through all these envs, it becomes too late and results in all sorts of issues and less confident release.

[@dpskatoo75]

Nice explanation, thanks!

[@Cognitive-Programmer]

Thanks for your comment 🙏

[@PiyushGhosh-l4k]

where to write this code of turning off the feature br changes before it is fully completed ???

[@ЕвгенийАндронов-ш4к]

Great explanation! Thanks!

[@Cognitive-Programmer]

Thanks Ford your comment 🙏

[@PiyushGhosh-l4k]

where to write this code of turning off the feature br changes before it is fully completed ???

[@anshulkatare]

Can you give an example of different strategies of different type of toggles. Also implementation of DI, Beans etc for it. Thanks

[@Cognitive-Programmer]

Thank for your comment.. If I understood your comment correctly.. strategy is what individual organisations and team domains.. the idea of dependency injection and beans are programming constructs used to implement new features It will need a separate video to explain 🙏

[@fahadaijaz4]

Great video

[@Brajgamer]

How refactoring fits into this? Since it can't be behind a toggle

[@Cognitive-Programmer]

Great Question? Consider refactoring as another piece of work, which can impact the existing functionality. you can do it in small steps, or create a short term toggle for the refactored code and then replace it after stabilization of the same. Hope I answered your question 🙏

[@Brajgamer]

@@Cognitive-Programmer Thanks for taking time to answer.

[@PiyushGhosh-l4k]

where to write this code of turning off the feature br changes before it is fully completed ???

[@ShariqueAkhtar99]

Pretty useful

[@Cognitive-Programmer]

Thanks for your comment 🙏