"Flagging your features — a DevOps approach to continuous release", Alex Thissen
•
0 gostou•63 visualizações
Your DevOps team wants to deliver business value as often and fast as possible. Ideally, you want to release a new feature whenever it seems ready. With feature flags you can achieve this selective releasing, but how do you do this in a structured and maintainable way that fits well with DevOps practices? In this session, we will look at the implementation of feature flags in cloud-native applications, the platform needed to support it, and some strategies and patterns related to feature flagging, such as rings and A/B testing. You will learn how to build and maintain this using the Microsoft platform with .NET applications, Azure and Azure DevOps. Also, we will cover how to get feedback from the feature flags and loop it back to the deployment and release pipelines and environments to achieve an automated and stable system during release. At the end of this session, you know how to get started with feature flags for continuous release DevOps style.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a "Flagging your features — a DevOps approach to continuous release", Alex Thissen
Semelhante a "Flagging your features — a DevOps approach to continuous release", Alex Thissen (20)
Mais de Fwdays
Mais de Fwdays (20)
Último
Último (20)
"Flagging your features — a DevOps approach to continuous release", Alex Thissen
- 2. Practicing DevOps Able to release multiple times per day Continuously deploy to production
- 5. Feature branching strategies New features are created in a separate branch Main Hotfix Release Dev Feature A Feature B Time Main
- 6. Reality of feature branches Team uses long lived branches Harder to merge Feature can only be released when complete
- 7. From feature branches to code branches Main Feature A Feature B if (feature.IsEnabled("NewSearchPage")) { // New feature implementation }
- 8. Features in a different way Back to “trunk based development” Push functionality when and to whom you want Be able to expand or “rollback“ without redeployment
- 9. Decoupling deployment from release
- 10. Why should you want feature flags? Code branch management Other reasons include
- 11. Original approach for a new feature New feature is included and replaces old Requires a rollback to revert to original code All or nothing releases
- 12. The new ‘if’ statement If statement evaluates state of feature flag First always off Incomplete feature can be still be deployed aka Toggle Router and Feature Toggle There might not be an original feature
- 13. Original feature Original feature The new ‘if’ statement New feature is ready for release Flag logic chooses when to route flow to new feature
- 14. The new ‘if’ statement Flags are released three times Flag logic needs to be removed
- 15. Feature flag categories Release Operations Experiment Permission • Performance related • Manual circuit breakers Short to long-lived • On/Off Kill-switch • Testing scenarios • Dynamic Short lived • Percentage • Time Window • Deploy incomplete code • Time release Short-lived • On • Off • Percentage • Targeted users • Defining cohorts User or request based • Claims • Cookies • Tenant
- 16. Feature management Rules and settings for evaluation in feature toggle Application Logic Rules Evaluates and filters on certain conditions Settings Determines flag state Multiple parameters
- 17. Feature context Named key-value pairs Different per environment Feature Value LeaderboardListLimit On APIv2 Parameters BetaWebsite Opt-in Feature Value LeaderboardListLimit Off APIv2 Off BetaWebsite Opt-in Feature Value LeaderboardListLimit On APIv2 Off BetaWebsite Opt-in
- 18. Ingredients for feature management In process service for evaluation Externalized storage of key/value pairs
- 19. Tools and platforms for feature management Microsoft .NET Feature Management RimDev.AspNetCore.FeatureFlags NFeature (GPL) Feature Toggle (Apache 2.0) Feature Switcher (Apache 2.0) FlipIt (Apache 2.0) Software as a Service Application Frameworks Esquio Platform as a Service
- 20. Health and metrics Telemetry is crucial to know about system stability
- 21. Absence of errors is not sufficient
- 22. Telemetry Essential to monitor your solution when toggling PASS PASS PASS PASS PASS FAIL PASS PASS PASS FAIL FAIL FAIL FAIL FAIL FAIL FAIL Gates indicate success Deployment still rejected Gate 1 Gate 2 Gate 3 Stabilization time Timeout Sampling interval PASS PASS Approve PASS
- 23. Telemetry Essential to monitor your solution when toggling PASS PASS PASS PASS PASS FAIL PASS PASS PASS FAIL FAIL FAIL FAIL FAIL FAIL FAIL Reject Gates indicate success Deployment still rejected Gate 1 Gate 2 Gate 3 Stabilization time Timeout Sampling interval PASS FAIL FAIL FAIL FAIL PASS PASS PASS PASS PASS PASS PASS PASS PASS
- 24. Development cycle with feature flags Deploy Release Gives more autonomy Flags introduce technical debt
- 25. Gradually exposing and releasing Rings Gradually increase blast radius Deployment: Feature: Cohorts Different size groups Can offer opt-in model
- 26. Early Adopters Canary Combe deployment rings and release flags Progressively reveal and expose features using flags
- 27. Blast radius of feature flags state Same principles as deployment
- 28. Pipelines with approval and gates for flags Gates Check performance metrics and alerts Allow or disallow next stage by approval Gates Check performance metrics and alerts
- 29. Testing in production Making it real QA and UAT where it matters
- 30. Test strategies A|B testing Dark launching Canary releases
- 31. A|B testing (aka split testing) Combine feature flag with experiment led by hypothesis Increase percentage that has feature enabled Measure results, outcome and gather feedback Previously: Routing to two different implementations Now: Percentage filter in single implementation
- 32. Dealing with technical debt Lifecycle of flag Remove
- 33. Smells Too many flags Flags used in multiple places Fine grained toggles Toggling business value vs technical capabilities
- 34. Pitfalls Combine feature toggles Complexity Dependent flags (one flag depends on other one) Long lived Launching in the blind (no monitoring) Unseparated control Don’t describe what toggle does Repurposing feature flags
- 35. Best practices Avoid flags as long-lived functionality Separate flag management from app Monitor usage of flags Enable just one toggle at a time
- 36. Tips and recommendations Add hardcoded fallback Start with master flags and add smaller flags later Define naming convention for flags
- 37. Questions and Answers Maybe later? @alexthissen athissen@xpirit.com