The Toggle Game

In the beginning, there was darkness. [[Launch Time]] [[Adventure choices]] [[Case study]]

#Hiya This is Toggle. <img src="/Toggle/img/ToggleMoon.png?raw=true" width=300 alt="Space explorer in space suit, blue and gray"> Toggle is a non-binary space explorer who works for SpaceLanes, Inc. Their job is to place markers on planets to help efficiently route spaceliners. Once a marker is placed, the home office can control it remotely. Pack everything Toggle needs for a trip! [[Rocket fuel]] [[Spacelane flags]] [[Swag]] [[All packed!|Adventure choices]]

#Adventure #choices Hey, folks! Let's choose our adventure. Each of these choices will lead you down a different deployment-style path. The goal of this game is to let you explore some of the ways you can use feature flags, progressive deployment, and multivariate delivery to change how your deployments work. (text-style:"rumble")[Where shall we go?] * [[Development]] * [[Design]] * [[O(o)ps|O(o)ps]] * [[Security and compliance]] * [[Sales and Marketing]] * [[User fun]] * [[Deployment]] * [[Architecture and Archeology]] * [[Case study]] <img src="/Toggle/img/ld_launchers.png" width=800 alt="Cartoon rocket ship with several explorers">

##Development You are a developer deploying your code to the trunk, but not always for external audiences. You don't intend to release it now, or you are not even in charge of releases. You might want to turn on features in these ways: [[Internal testing]] [[Visibility]] [[Merging]] [[Deleting!]] [[Back to Adventure Choices|Adventure choices]] <img src="/Toggle/img/sticker_black_bg.jpg" width=500 alt="LaunchDarkly rocket sticker on a celestial fabric background">

##Design Using feature flags for design is a way to give designers and product owners control over the user experience without having to go back to development with requests for every change. Design choices with feature flags could be either from the product side - things like A/B testing or experimentation, or it could be driven from the user-side - things like setting your accessibility preferences or colors. <img src="/Toggle/img/Toggle_launching.jpg?raw=true" width=300 alt="An illustration of Toggle launching something darkly, tinkering with a rocket in a dark room"> [[A/B testing]] [[White-labeling]] [[Custom documentation]] [[Accessibility]] [[User colors]] [[Back to Adventure Choices|Adventure choices]]

##O(o)ps Ops is full of people who care about things working. They care passionately and they spend a lot of time thinking about it, but that doesn't mean that it's always easy to keep things up and running - IT systems, like spaceships, are complex and have a lot of moving parts. Like spaceships, you need to fix small problems quickly before they become Very Large Problems. Some of the ways to short-circuit problems are failovers and kill switches. Some of the ways to prevent them are progressive deployment and extensive testing. <img src="http://www.heidiwaterhouse.com/wp-content/uploads/2017/10/20171001_192012.jpg" width=500 alt="A sticker of Toggle floating sideways on a nebula fabric"> [[Failover]] [[Deployment failure]] [[Kill switch]] [[Deployment]] [[Back to Adventure choices|Adventure choices]]

##Sales and Marketing There is an art and science to sales and marketing, and those teams often have very clear and compelling use cases for being able to control what features a user has or demonstrate what is possible. Sales teams might want to be able to customize [[currency|Currency]]. Marketing teams might want to target specific [[segments|Market segments]] of the user base. Either team wants to be able to make sure that customers paying for premium features can get them easily and instantly. <img src="/Toggle/img/20171001_191941.jpg" width=300 alt="Toggle sticker on a pale background, giving a thumbs-up"> Here are some examples of settings that can be tweaked: [[This or that?|A/B testing]] [[Currency]] [[Market segments]] [[Feature tiers]] [[Tutorials]]

##User settings <img src="http://www.heidiwaterhouse.com/wp-content/uploads/2017/10/20171001_191542.jpg" width="500"> Whatever their goal, we want to make sure the users, and the travelers, get the experience they are hoping for. For the travelers, they expect to get where they're going with a minimum of space-turbulence, and they expect astronaut ice-cream if they bought the deluxe meal plan. In software, we want to give users what they expect, or possibly a couple small, pleasant surprises. Large changes that they can't control are just annoying. What can you put under user control, instead of assuming that everyone wants the same design? [[User colors]] [[Accessibility]] [[SSO customization]] [[Localization]] [[Back to Adventure choices|Adventure choices]]

##Deployment When Toggle plants a flag, nothing much happens right away. They report the code back to headquarters, and headquarters plots it on a map. Toggle goes on to the next exploration zone. When the new route is fully plotted and connected to the network, the headquarters team sends through some test shuttles to see how well the route works and how fast it is. When they are satisfied it is safe and efficient, they send the spaceliners through. Toggle might be halfway across the quadrant by then. Deployment is not the same thing as activation/launch/release. You need to think of deployment and release as different things before feature flags will seem useful to you. Here are some ways that feature flags can make your deployment process more granular once you have released your feature. <img src="http://www.heidiwaterhouse.com/wp-content/uploads/2017/10/20171001_190738.jpg" width=300 alt="A small blue planet floats on a field of stars> [[Canary launch]] [[Albatross launch]] [[Market segments]] [[Kill switch]] [[Internal testing]] [[Adventure choices]]

(enchant: ?Page, (background: "none")) ##Colors (background: #ff00ff)[Users have a lot of feelings about their interfaces.] (text-colour: white)[Some of us need high-contrast text to read.] (css: "font-size: 200%")[Some of us need larger text.] When we give users control over their visual experience, we aren't just making it so they can customize it to be visually appealing, we are also adding accessibility for people who have low vision or color-blindness. [[Accessibility]] [[SSO customization]] [[Back to User fun|User fun]] [[Back to Adventure choice|Adventure choices]]

##Accessibility Different accessibility fixes sometimes conflict with each other. Increasing font size to help with low vision may be the wrong choice for a user whose primary concern is screen readers. Captchas may rely on vision and exclude users who need audio prompts. Allowing users to choose the accessibility features that they want is empowering and useful. We have learned from Universal Design that adaptations originally intended for people with disabilities are actually useful to a large number of people. People with normal hearing may use screen captions to watch movies without disturbing others. People looking at their phones may notice the tactile difference of textured curbs. People with strollers and wheeled suitcases may use ramps and curbcuts. The more accessibility customization we build in and allow, the better it is for everyone. We are all only temporarily able-bodied. [[User colors]] [[SSO customization]] [[Localization]] [[Back to User fun|User fun]] [[Back to Adventure choices|Adventure choices]]

##Internal testing Dogfood is for developers, but internal testing can be a larger group within your company. For example, what if you open testing a new feature to your training or support team so they can prepare for it before it rolls out to the public. They may catch workflow or technical problems that developers wouldn't notice. Toggle isn't part of the Canteen Crew, but they do help out by testing space-stable rations. The persimmon flavor is really good! [[Canary launch]] [[Albatross launch]] [[Market segments]] [[Kill switch]] <img src="/Toggle/img/persimmon.jpg" width=300 alt="Dried persimmons getting ready for space"> [[Back to Deployment|Deployment]] [[Back to Development|Development]] [[Back to Adventure choices|Adventure choices]]

##Canary launch <img src="https://wiredferret.github.io/Toggle/img/nest-79765_960_720.jpg" width="500" alt="A nest of swallows"> A canary launch is a way to safety-test your release. You can choose a small percentage of users who will get the new feature, and closely monitor the analytics for their experience. Canary launches reduce the risk that you might roll out a bad change to your whole userbase. Canary launches can also be used to get information about more than just your application reliability. You can use them to explore sentiment around interface changes or detect how much load a new feature will add to your needs. [[Internal testing]] [[Albatross launch]] [[Market segments]] [[Kill switch]] [[Back to Deployment|Deployment]] [[Back to Adventure choices|Adventure choices]]

##Albatross launch <img src="https://wiredferret.github.io/Toggle/img/rover airbags.jpg" width="500" alt="Design for airbags to cushion a Mars rover"> You know that customer who is still using Internet Explorer 6, and won't leave it, and won't continue to buy your product if you stop supporting it? They are an albatross. They're big - they give you a lot of money, so you don't want to lose them as a client, but you also don't want to tell anyone else in the world that you're willing to support IE6. Use an albatross flag to continue support only for them while the rest of your users will not see that legacy support and ask for it themselves. Sometimes things have to last a long time without updates, when they're in space. [[Internal testing]] [[Canary launch]] [[Market segments]] [[Kill switch]] [[Back to Deployment|Deployment]] [[Back to Adventure choices|Adventure choices]]

##Segments <img src="https://wiredferret.github.io/Toggle/img/pie slices.JPG" width=500 alt="Slices of different kinds of pie"> Your maketing department is full of people who can tell you an amazing number of things about your users, like how they are distributed by age, and what other products they are likely to buy. Depending on your size, marketing has likely already defined several *segments* of people who have different interests, ways of using your product, use cases, or other defining characteristics. You can work with marketing to make sure specific features are delivered to exactly the targeted demographic and no one else. [[Internal testing]] [[Canary launch]] [[Albatross launch]] [[Kill switch]] [[Back to Deployment|Deployment]] [[Back to Sales and Marketing|Sales and Marketing]]

##(text-style:"blink")+(text-color:"yellow")[aOOOga!]  Something has gone very wrong with a feature, and you need to get it out of production fast! You might be making bogus stock trades or spamming your cloud provider, or spinning up hundreds of thousands of VMs a minute, but whatever it is, time is of the essence. Since you wrapped the feature in a flag, all you have to do is turn the flag off. If your flag management system is push-based, the change will happen very rapidly, almost instantly. If the system is based on polling, it will turn off as soon as a request can be returned. Either way, it will probably be much faster than finding a build that doesn't have the problem and deploying it to everyone. For SpaceLanes, flipping the kill switch means that no liner will be routed near the problem until we figure out what's going on. Because sometimes what's going on is Not Good. <img src="/Toggle/img/black_hole.jpg" width=500 alt="Artist's rendering of a black hole"> [[Internal testing]] [[Canary launch]] [[Albatross launch]] [[Market segments]] [[Back to Deployment|Deployment]] [[Back to O(o)ps|O(o)ps]]

##Visibility Test in production, but not where anyone can see. <img src="/Toggle/img/magic_eye.png" width=500 alt="Magic Eye puzzle, apparently random dots"> The goal is to have the ability to test your new feature against all the things that are unique about production, such as weird user accounts, message volume, scale, speed, latency, and other factors. The other goal is to never have a user complain because our testing broke their experience. Visibility is being able to control exactly who sees the feature. That might be just yourself, or your team, or anyone in your company. It might include a small number of customers or test users. It's up to you, and being able to make these choices gives you more power. [[Merging]] [[Deleting!]] [[Internal testing]] [[Back to Development|Development]] [[Back to Adventure choices|Adventure choices]]

##Merging <img src="/Toggle/img/cooked-fresh-spaghetti.jpg" width="500" alt="Tangle of cooked spaghetti noodles"> One of the most stressful parts of developing in a team is making sure that your code fits in with other people's work without anyone causing problems for each other. This is especially difficult when everyone is working in individual development branches that aren't visible. The act of moving code into a shared context and reconciling it is called merging. Merging is much less of an issue if everyone has their code in the same location because they are doing trunk-based development. Use feature flags to keep unfinished code from being revealed to users while your teammates can still see it. [[Visibility]] [[Deleting!]] [[Back to Development|Development]] [[Back to Adventure choices|Adventure choices]]

#Currency <img src="https://wiredferret.github.io/Toggle/img/currency.jpeg" width="500" alt="Stack of currency from different countries"> Currency is a an interesting problem when you are a global sales organization. You want to accurately report the price of something, but you have a lot of complications. Not only are there currencies with different symbols, there are also currencies that have the same symbol and name, but different monetary values. For example, a $(USD), a $(CAD), and $(DOP) are all different currencies with different values. How do you ensure your customers are seeing the right price? One way to do this is to detect where your user is, based on information they provide or browser or IP settings. Use flags to keep your underlying code consistent while making sure you give everyone the currency that is appropriate to their country. How do you want to get paid? Toggle gets paid in bars of gold-pressed latinum, but you may want to switch your prices from US dollars to Canadian dolllars, or yen or pesos or euros. [[Feature tiers]] [[Tutorials]] [[Market segments]] [[Back to Sales and Marketing|Sales and Marketing]] [[Back to Adventure choices|Adventure choices]]

##You get what you pay for Sometimes we want our users to have different experiences, depending on what they paid for. If a customer has chosen a premium experience and paid to avoid ads and see extra features, you can put that experience in a flag and continue to have a consistent code base that serves all your types of customers. You can also use flags to control the access to a trial or beta feature for customers who are still deciding to purchase. Super-luxury spaceliners are fast and comfortable, but they cost a lot to fly on. Toggle knows that if you're willing to fly in a smaller cabin, you can save a lot of gold-pressed latinum. It's the same spaceliner, but different experiences. Sometimes we want our users to have different experiences, depending on what they paid for. [[Currency]] [[Tutorials]] [[Market segments]] [[Back to Sales and Marketing|Sales and Marketing]] [[Back to Adventure choices|Adventure choices]]

##Tutorials It's valuable to offer users who are new to an application or feature a tutorial that gives them hints and instructions about how to use it. However, that same helpfulness can be annoying for experienced users. Users should be able to turn off helpful tools when they are done with them, and one way to offer that capability is to expose a flag control for the tutorial to the user. <img src="https://wiredferret.github.io/Toggle/img/slack.jpeg" width="500" alt="Image of the old Slack icon"> For example, when you log into a new Slack channel, it ask s you if you already know what's going on, and if you do, you don't have to do the whole orientation again. [[Feature tiers]] [[Currency]] [[Market segments]] [[Back to Sales and Marketing|Sales and Marketing]] [[Back to Adventure choices|Adventure choices]]

##Failover You have a backup, right? <img src="https://wiredferret.github.io/Toggle/img/crash.jpg" width="500" alt="A crashed experimental jet in a desert with sad technicians standing around it"> Have you tested it? Because if you haven't, it's not a backup, it's a security blanket, and about as useful in case something goes wrong. When something goes wrong in your infrastructure and deployment setup, you want to be able to redirect traffic automatically, since people are the slow, meat-based part of any operations system. Using feature flags, APIs, and monitoring, you can set up your system to change to a different feature set, different hardware set, or different configuration without needing to redeploy any software. [[Deployment failure]] [[Kill switch]] [[Deployment]] [[Back to O(o)ps|O(o)ps]] [[Back to Adventure choices|Adventure choices]]

##Fail forward One failure, many successes <img src="https://wiredferret.github.io/Toggle/img/Upgrading_Hubble_during_SM1.jpg" width="500" alt="Technicians working on the corrective lens for the Hubble telescope"> In systems with large bundled deployments, a failure in any feature may mean that the whole deployment must be rolled back. If each feature has an individual control, then you can turn off the malfunctioning feature and leave the rest of the deployment package working. This is sometimes called *failing forward*. [[Kill switch]] [[Failover]] [[Back to O(o)ps|O(o)ps]] [[Back to Adventure choices|Adventure choices]]

##Rocket fuel You're going to need some rocket fuel to get going. Have you loaded it carefully? You don't want the elements to cross over or mix too early. <img src="/Toggle/img/dietcoke_and_mentos.JPG" width=500 alt="Diet Coke and Mentos prepped to make a dramatic fizzy fountain"> Rocket fuel is two unstable elements that get combined right before takeoff. This is sort of like deploying your code darkly and then turning it on when you're really ready to launch. [[Spacelane flags]]

##Spacelane flags Toggle's spacelane markers look like this: <img src="/Toggle/img/heliograph_1.jpg" width=500 alt="Heliograph, a mirror used to send messages long distances with flashes of sunlight"> The way that we label our flags changes how we think of them, how long they should last, and who can see them. [[Swag]] [[Rocket fuel]]

##White-labeling <img src="/Toggle/img/Generic_Cola_Cans_1980s.jpg" width="500" alt="Generic cola cans, with labels that are not branded"> White-labelling is putting customer branding on something that was created to be resold. For example, Shopify makes shopping carts for many different retailers, but those retailers can change the way the cart looks and feels to match with the rest of their site. For some software companies, they provide the branding changes as part of the service to their customers. The problem with white-labeling is that it is easy to end up with a branch for each client, but then it is difficult to update each branch accurately with identical changes as the underlying platform changes. Feature flags solve this problem by making the cosmetic changes a flag for each client, and the core code stays unified and easy to update. [[Custom documentation]] [[A/B testing]] [[Back to Design|Design]] [[Back to Adventure Choices|Adventure choices]]

##Custom documentation What people want, when they want it. It's frustrating to page past or search through documentation that covers features you don't have or platforms you're not using. One of the things you can use targeted delivery for is tuning your documentation to reflect the parts of the product the customer has, and only giving them what they need. Flagging documentation and tutorials and interfaces to reflect the package the user has is a way to make them feel like they are getting the correct experience. <img src="https://wiredferret.github.io/Toggle/img/highlighting.png" width="300"> [[Disguises|White-labeling]] [[A/B testing]] [[Back to Design|Design]] [[Back to Adventure choices|Adventure choices]]

Let's talk about how a hypothetical spaceline company added feature management using flags. Which do you think they chose to start with? [[Terraforming|Retrofit]] [[Unexplored planets|New feature]] <img src="/Toggle/img/20171001_190659.jpg" width=500 alt="Image of a binary planetoid on a starry background">

##Unexplored planets This is the green field scenario, where you're creating fresh code from scratch and everything is new and shiny. It's really easy to start using feature flags in this case, because all you have to do is create a feature flag, and then fill in the feature as you go along, and nothing will change until you turn it on. <img src="https://wiredferret.github.io/Toggle/img/green-field-background-1467561007tvE.jpg" width="500" alt="Picture of a greeny, idyllic field"> But you still have to decide which development method you'll be using. Are you going to create a feature branch, or will you put all your code in trunk as you're writing it? [[Git and branches]] [[Flags and mainline]]

#Retrofit Nothing is new between the suns. Most of us don't get to start with an entirely fresh environment to do whatever we want with. Instead, we're going to have to work with an existing code base and figure out how to convert it. Toggle is looking into moving through settled space and working to understand how best to do their work. There are three main proposals. Which do you vote for? [[Slow and steady]] [[Only new features]] [[Rip off the bandaid]] <img src="http://www.heidiwaterhouse.com/wp-content/uploads/2017/10/20171001_190738.jpg" width=700>

##Git and branches <img src="https://wiredferret.github.io/Toggle/img/git branches.png" width="500" alt="An array of intimidating git branches"> As the spacelanes are explored, each one is marked with a proprietary labeling system unique to the company that set them up. Sometimes the companies want to combine their businesses or routes, and then someone has to make sure that the different route markers all work together to get passengers where they're going. The best way to do that is to look at a big map overview and see if everything matches or if people need to make some choices about what has to get dropped. [[Planet 1|Goes fine]] [[Planet 2|Merge conflict]] [[Planet 3|Git trauma therapist required]]

##Flags and trunk development The new CTO at Spacelanes, Inc. is committed to Continuous Deployment and Integration. They want to be able to deploy dozens of times a day and turn features on and off when they're ready. The only way to do this is to make it so that planets aren't online until everything is ready, even if they have been explored and marked. Once the full path has been checked for hazards, then you can turn on the markers that send people that way. Since you don't know how it's going to go, which planet would you like to try first? [[Planet Up|Deploy darkly]] [[Planet Charmed|Feature failed fast]] [[Planet Gluon|Slow your roll....out]] <img src="https://wiredferret.github.io/Toggle/img/montage.jpg" width="500" alt="An array of planets (and moons)">

##Everything goes fine Congratulations! You've successfully used branching development to create and release the routes for Spacelanes, Inc. <img src="https://wiredferret.github.io/Toggle/img/space_cake.JPG" width=500 alt="An array of space-themed cakes and cupcakes"> Ready for your next assignment? [[Adventure choices]] [[Case study]]

##Merge conflict <img src="https://wiredferret.github.io/Toggle/img/collision.jpg" alt="A galaxy collides with another" width="500"> Well, it's not often that a space traveller ends up in this mess, because space is pretty big, but two objects can't occupy the same space at the same time. If Toggle and another scout put down beacon flags on the same bit of space rock, then the home office has to talk to the other corporation and either disable one of the flags or do some fancy work to offset the timing of the beacons. It's kind of a headache and no one likes it. Toggle thinks this would all go better if people could just use the same flags for every spaceliner company. Try again? [[Left planet|Goes fine]] [[Right planet|Git trauma therapist required]]

##Git Trauma Therapist required <img src="http://www.heidiwaterhouse.com/wp-content/uploads/2017/10/img_0830.jpg" width=500" alt="A rainbow-colored manatee with the caption *Oh the hue manatee*"> Something has gone super wrong. The spaceliner keeps seeing the flag on the other side of the Planet Cherry and going around and around in an orbit instead of on to the next flag. One of these flags is obviously wrong and needs to be turned off, but which one, and when? We can't leave these people pointed the wrong direction. Try again? [[Top planet|Goes fine]] [[Strange planet|Merge conflict]]

##Deploy darkly Deploy and test quietly, before the crowd. <img src="https://wiredferret.github.io/Toggle/img/Toggle_launching.jpg" width=500 alt="Toggle in a dark room, working on a secret launch by the light of a cracked door"> You got everything tested, it works great, and no one has any complaints. All the things that were bumpy or difficult for Toggle as they traveled the spacelanes are smooth and easy for the spaceliners. Congratulations, team! Ready for your next assignment? [[Case study]] [[Adventure choices]]

##Feature failed fast That's not gonna work! Welp. Toggle though they had a good idea on how to get through this asteroid field, and then it turns out they were wrong and this is a dead end. Toggle is going to have to backtrack and pick up that last flag marker, but at least it's not a big deal. <img src="https://wiredferret.github.io/Toggle/img/fail.jpg" width="500" alt="An ominous glowing orb"> Try again? [[Planet Muon|Deploy darkly]] [[Planet Eta Ceta|Slow your roll....out]] [[Back to Case study|Case study]]

##Slow your roll...out Too much! Let's slow that down. Some of the spacelane routes are going to be super popular when they open, but if everyone starts out down the same path from Earth the minute they open, there will be a traffic jam. Instead, SpaceLanes is going to meter the traffic so that there is room for everyone. Some people will start a little later, but everyone will get where they are going without overwhelming the system. <img src="https://wiredferret.github.io/Toggle/img/slow_down.jpg" width="500" alt="A curl of multicolored light down a road lit by stars"> Try again? [[Planet Erehwon|Feature failed fast]] [[Planet Ruritania|Deploy darkly]] [[Back to Case study|Case study]]

#Slow and steady Conversion is slow, but it will get us there eventually. Instead of doing a big surge or only flagging new features, features are converted as they are touched or opened. The spaceliner doesn't actively convert markers from one type to another, but if a marker needs repair, it is replaced with the upgraded version. <img src="https://wiredferret.github.io/Toggle/img/rivets.jpg" width="500" alt="Photo of rivets in metal, black and white"> [[Works great]] [[Training is hard]]

##Just the news Only new features get flags. There's no business case for going back and changing the way existing features are managed. The old system is working fine and doesn't need to be changed where it already exists. Instead, every time a new planet is discovered, it is fitted out with the new signal system. As time goes on and older planets become less relevant, it doesn't matter that they still have old systems. [[Training is hard]] [[Works great]]

##Rip off the bandaid This is gonna hurt, but only for a bit. Sometimes the best way to handle updating a code base is to dedicate time to it and all work together to make it happen. It stops your progress on anything else, but it can be very fast and efficient since the same tasks are repeated over and over. The spaceline needs to change over the way they direct ships around, and all of the existing methods on established planets are outdated. For one astral month, they dedicate all their resources to replacing old signals instead of exploring and planting new ones. At the end of that time, the core systems are all updated. <img src="https://wiredferret.github.io/Toggle/img/bandaid.jpg" width="300" alt="An array of colorful banages"> [[Training is hard]] [[Works great]]

#Training is hard Teaching people to change the way they work requires everyone to make a conscious effort, and it means that people who used to be really fast at their job are a bit slower. It's hard, and people resist it. But even if it's difficult, we can get through all sorts of things as a team, and we'll get through this change in scout ships together. Toggle is a little dubious - they love their scout ship, but they agree that something that seems slow and difficult now will probably get easier as they get used to it. <img src="https://wiredferret.github.io/Toggle/img/ThumbsUpDark%402x.png" width="300" alt="Toggle giving a thumbs-up"> [[Works great]] [[Back to Case study|Case study]]

##Everything works great Toggle loves everyone in this space cantina! <img src="/Toggle/img/20171001_192030.jpg" width=400 alt="A sticker of Toggle on a red nebula background"> That was not easy, and Toggle had some long, lonely moments as they worked in the Big Black Beyond, but they knew they could always ansible their team for cat pictures. <img src="/Toggle/img/cat.jpg" width="400" alt="It's a cat!"> To celebrate the opening of 500 new spacelanes, Spacelanes, Inc. has called in all the scouts like Toggle, and invited all the ship technicians and spaceliner crews, and office staff to the Best Space Cantina Ever. You would not believe Toggle's zero-G dance moves. They have had a lot of time to practice. [[Case study]] [[Adventure choices]]

##A/B testing <img src="https://wiredferret.github.io/Toggle/img/ab_testing.jpg" width="300"> A/B testing is traditionally a way to test out how audiences react to a small interface change by delivering the variant to half the users. Many organizations do this with full statistical significance and rigor, but others use it to confirm or deny theories about interface preferences without an experimental framework. Many A/B tests are run with load balancers or other methods, but using a feature flag to control who sees a variation allows you to do tests quickly and without needing active development involvement. You can also do tests that have more than one variation - A/B/C/D/etc tests. There's no One True Way to use feature flags, just ways that we are all trying out. [[Design]] [[Custom documentation]] [[White-labeling]] [[Back to Design|Design]] [[Back to Adventure Choices|Adventure choices]]

##Single Sign-on <img src="https://wiredferret.github.io/Toggle/img/Minuteman_launch_key.jpg" width="500" "Minuteman launch key - a set of two turnkeys on an old-looking metal electronics console.> If you know who someone is because they have logged into your site, you have the opportunity to give them a custom experience with all the flags set the way they want them. You can add greetings and customization, make sure they have access to everything they pay for, and keep their experience seamless. It's important to use this customization in accordance with your privacy policies, but if you have an existing relationship, make your space a comfortable place for people you already know. There's nothing like hooking into a docking bay that already has the right atmosphere and gravity conditions to make it easier to concentrate on repairs, Toggle thinks. [[User colors]] [[Accessibility]] [[Localization]] [[Back to User fun|User fun]] [[Back to Adventure choices|Adventure choices]]

##Swag Just like Toggle, I have a team that makes navigating deployment and release much faster and safer. We provide feature flags as a service, and if you'd like to know more about that, you can visit: ''http://go.launchdarkly.com/heidi'' They'll be happy to send you a free t-shirt and some stickers of Toggle. <img src="/Toggle/img/LaunchDarklyBayBridge.jpeg" width=700 alt="The Bay Bridge is prettier than the Golden Gate"> [[Adventure choices]] [[Case study]]

(css: "font-size: 50%;")[@wiredferret | LaunchDarkly]

##Security and compliance We are all trying to be DevSecOps, right? Let's talk about how flags can help with security. If you're using environment variables, it may be difficult to trace and report any changes in an auditor-friendly fashion. When was the change made, who made it, and what did it do? You may also want to be able to control who has access to which flags. After all, it may not be a good idea to give the operations team the ability to turn off a long-running marketing test by accident, or allow just anyone to flip a feature kill switch. Here are some options for flag settings that can help you make your compliance team happier. [[Private attributes]] [[Auditing]] [[RBAC]] [[Back to Adventure Choices|Adventure choices]]

##Private attributes When you set an attribute as private, all of the values in the attribute will stay on your side, and you won't be sending anything "across the wire". Instead, the targeting rules will evaluate the value at the endpoint. Toggle uses this setting when they run across a planet that would rather stay off the spaceline path. They do leave a flag, but the spaceliners won't stop there. Developers use this setting to ensure that protected data doesn't leave their secure environment. [[RBAC]] [[Auditing]] [[Security and compliance]] [[Adventure choices]]

##Auditing You don't want to be solving a mystery with no clues. And you don't want to face an auditor like this: ¯\_(ツ)_/¯ Auditing means that all the changes you make to flag targeting or flag state are stored on a third-party server and available for review at any time. For example, an audit entry may include the time and date the flag was changed, the person who changed it, and what the final state is. Secure audit logs are especially important for organizations who need to be able to prove that only authorized administrators can change the user experience. [[RBAC]] [[Private attributes]] [[Back to Security and Compliance|Security and compliance]] [[Back to Adventure choices|Adventure choices]]

##Role-Based Access Control Who gets to change settings? Who gets to see everything? Use roles to sort people, instead of manually adding them. Role-based access control means that an administrator's ability to change the code is derived from the same place as their permissions to control other parts of your infrastructure. Setting a new administrator's security and privileges is as simple as adding them to a group with designated roles. For Toggle, this means that all scouts can access any other scout's ship, in case of emergencies, but Toggle doesn't have the access to turn on the signal flags - only SpaceLanes HQ can do that. [[Private attributes]] [[Auditing]] [[Back to Security and Compliance|Security and compliance]] [[Back to Adventure choices|Adventure choices]]

##Architecture and Archeology Space can be a world of spheres, but we think in terms of arches. <img src="/Toggle/img/star_arches.jpg" width="500" alt="Beautiful architectural arches"> <small=Image by https://www.flickr.com/photos/gerlos/> How do we build something new that will persist? How do we uncover and understand what happened in the past? The questions that we ask when building and exploring determine a lot about how our adventures end up. [[Architecture]] [[Archeology]] [[Back to Adventure choices|Adventure choices]]

##Architecture * Do I want this forever or just for now? * Does this do one and only one thing? * What is the failsafe position? * What's the point? Feature flags can encourage good programming practices by encouraging us to think through the purpose and function of the thing we are building. These questions help us consider our purpose. Is this flag just for a temporary use, to add something to the deployment safely, or is it a control handle for a feature that may be used in the future? Am I mixing up more than one behavior in this feature, and is that a good choice? What should happen if the flag isn't on? [[Archeology]] [[Back to Adventure choices|Adventure choices]]

##Archeology * What was the plan? * Can I nuke this from orbit? * What were you thinking? One of the hardest parts of a shared development code base is figuring out what your teammates were trying to do. Theoretically they signalled their intent with comments, but that's not always true. Feature flags can contain a lot of information about intent and purpose, both in their name and in the if/then statement that describes the targeting. [[Architecture]] [[Back to Architecture and Archeology|Architecture and Archeology]] [[Back to Adventure choices|Adventure choices]]

##Localization Localization is more than translation, it is making your app behave in a way that makes everyone feel comfortable, no matter what their language or country. Some features flags for localization might include right-to-left text, language, [[currency|Currency]], regional jokes, even interface [[color|User colors]]. Using flags could allow you to pull in information from translation files to present in the interface without needing to include and deploy the files. That gives your translation teams more time to work. Toggle uses this kind of setting all the time, since different regions of space have different conditions. Sometimes it's faster to be able to pay for Space Slurpees in the local currency, rather than the exchange from universal. [[User colors]] [[Accessibility]] [[SSO customization]] [[Back to User Fun|User fun]] [[Back to Adventure choices|Adventure choices]]

##Deleting! It has been said that the best code diff is a red diff -- deleting code, features, and other old unused parts of your codebase is an essential part of making it readable, usable, secure, and stable. But sometimes it's nervewracking to delete something that *may* still be needed. One way to handle this uncertainty is to flag the section that you are thinking of removing. This works like commenting it out, but you can also use it in a more nuanced way, for example turning a feature down gradually, or eliminating it from only certain segments of users. <img src="/Toggle/img/red_diff.png?raw=true" width="500" alt="Source control showing red and green diffs"> [[Visibility]] [[Merging]] [[Back to Development|Development]] [[Back to Adventure choices|Adventure choices]]