BROADCASTS.com

b'This podcast features people doing interesting work in the world of Cloud. What is the state of the technical world? Let\\u2019s first focus on the up or down, on or off function of feature flags.\\nToday, we\\u2019re talking to Heidi Waterhouse, a technical writer turned Developer Advocate at LaunchDarkly, which is a feature flag service - a way to wrap a snippet of code around your feature and make it into an instrument to turn on or off. It lets you turn things on and off in your codebase quickly without having to do several commits. However, it is difficult to track it when there are more than about a dozen flags. So, LaunchDarkly provides a way to manage your features at scale with a usable interface and API.\\nSome of the highlights of the show include:\\n\\nA feature flag allows you to hide items before you want them to go live on your Website. You hide it behind a feature flag, doing all the work ahead of time. Then, at some point, you turn it all on instantly without the risk of pushing untested code into your production.\\nYou can test at scale to gain authentic data. Test something with your team, your company\\u2019s employees, your customers, etc. However, no matter how good your integration tests are, there\\u2019s always wobbles to watch for in the system.\\nWith implementation, there are a few paths that can work, such as the massive reorganization path. Or, you can just start incrementally with feature flags for new features.\\nLaunchDarkly thinks in the Cloud as the surface because it mostly works with people who are doing Web-based delivery of features.\\n\\n\\nMajor companies, like Google and Facebook, offer services similar to feature flags for their own development. They\\u2019re operating on such a giant scale that they have internal teams doing it.\\nCompanies use feature flags on the front-end and other purposes. It works through the whole stack from frontend page delivery, pricing tiers, white labeling, style sheets, to safer deployments.\\nDo not focus on documentation. You should not have to read documentation for anything that you don\\u2019t own. Every feature should have documentation tied to its code. Create a customized experience.\\nFeature flags effectively manage and minimize risk. There is always risk in the world, but what causes disaster is not just one failure. It is a multiplication of failures. This goes wrong and that goes wrong. Feature flagging breaks monolithic releases into tiny chunks that can go forward or backward.\\nLaunchDarkly holds monthly meet-ups called, Test and Production. People share their use case regarding continuous integration, continuous deployment, DevOps, etc.\\n\\nLinks:\\n\\nLaunchDarkly\\niPad\\nAutodesk\\nSlack\\nIBM\\n\\nQuotes by Heidi:\\n\\u201cWhat feature flags do is make it possible for you to push out a deployment with things hidden, we call it launching darkly.\\u201d\\n\\u201cWe\\u2019re all about avoiding risk, I think this is our motto this year, eliminate risk\\u2026you can\\u2019t eliminate risk, but you can make it much less risky.\\u201d\\n\\u201cGo ahead and write your feature. You know that it\\u2019s hidden behind the magical feature flying curtain until you\\u2019re ready to turn it on.\\u201d\\n \\u201cIf 20 years of technical writing taught me anything, it\\u2019s that nobody wants to be reading documentation.\\u201d'