 No matter what industry you're in, chances are your business depends on delivering a great digital experience to your customers. That product experience is made up of features, both big and small, that influence how your app performs. Naturally, you want customers to react positively to those features. But it's a known fact that 80 percent of features go unnoticed. Wouldn't it be nice if you could test your features to figure out what's working? That's where we come in. Split is an enterprise-scale feature delivery platform that allows you to combine data about your customers with data about your features so that you can see what works and what doesn't, adapt for the market, and maximize impact for your customers. With Split, your developers can release, monitor, and experiment. And it's all powered by Feature Flags. A Feature Flag is a switch or toggle that allows you to turn app features on and on without requiring a new code deployment. By using Feature Flags to release different versions, you can test how new features are performing and clearly see what drives the best results for your business. Let's say you want to A-B test how new app feature impacts engagement. Simply use Split to turn on that feature for a specific segment of customers. Measure which feature performs best in real time and use that data to decide whether you should deploy, improve, or kill the feature. With an end-to-end feature delivery platform like Split, you can test multiple features at once. This means you can continue to update your product without the risks of large-scale releases. Best of all, you'll have the confidence of knowing that your product's development is guided by the most important stakeholder of all, your customers. Software development teams use Split to release code faster and safer, minimize the impact of bad code, and test-improve their best ideas. To learn more about how Split can help your business, contact us to schedule a demo. And you've contacted me. Hi, I'm Jay Gordon. I am here as your host of Azure FunBytes, where we get together every week and what do we do? We talk about the people, the products, the fundamentals that make up an incredible Azure experience. And so I wanted to say thank you so much for being part of this. I always love having you all taking part in the questions, in the chat, all that stuff. It's not going to happen this show without you being part of it. And so thank you so much. I want to go ahead and start talking a little bit about what we're going to be talking about today. And so I showed you that intro video about Split. Split is a company that produces ways of you being able to develop and deliver software faster and safer. And we're going to talk a little bit about feature flags, what they are, why they are, how we can implement them and also make them part of our CICD process using Azure DevOps. And to help me do that today, I have a really great guess. So I want to bring him in now from Austin, Texas. It's David Brooke Martin. You are a senior evangelist. I'm sorry, let me bring it up. I actually still have the word engineer in my title. I'm going to talk a little bit about that. Senior Solutions Engineer is what I got here. Thank you so much, David. How are you today? I'm great. I'm fine. You know, I have to ask you that cute raccoon in your logo. Is that an Azure thing or is that an Azure FunBytes thing? Did you guys do that? So a couple of years ago, Ashley that works on our team in the Great DevRel organization created this little guy. His name is Bit. Bit. And Bit, yeah, let me bring him up for just a second. And Bit has a hankering for junk food, apparently. Yes, well, you know, you can see him up in the right bit. You know, he's kind of like representative of what developer advocacy is, which is the idea that we're kind of like trash pandas. We're kind of like raccoons. We go and we find the things and we make use of it. We get messy and we're able to kind of take that mess that we've made and show others how to actually implement it. I'm glad to be your today as a trash. It's an honor. Thank you for having me. Well, you're certainly not trash. You are very, very special to us because you are an Azure FunBytes guest. And as an Azure FunBytes guest, you win the prize of spending an hour with lovely me. Thank you. Yeah, so it's an honor to be here. Thank you very much. I really do appreciate it. And I want you all to remember a few things that we do every single week. I want to know, are you currently using feature flags when developing your applications? You can let me know a little bit more about it by going to aka.ms slash learn TV. You can vote. Look how easy it is. I'm just going to go here and I'm going to say yes. And we've gone ahead and voted. So why don't you go and vote? And if you also go on the right side, you'll be able to see there's some documentation up for today's show that includes links to splits website. So please go. Yes. And if you want your $200 and free Azure credit, I believe it's up to a year and certain free services and some other services that never cost. You can go to the Azure website and or you can go to this short link, cda.ms slash 219 that'll get you there. Also, if you'd like to get some free education, more freebies, more freebies. You can head over to Microsoft Learn. If you're already on Learn TV, you'll know how much education and learning about Azure means to us. And also, you know, learning about different products that will actually help you have a better Azure experience. And I think that that's one of the things that we're going to be talking today about split, how split fits into the feature flag story and how our our users can make best of it to create that else if kind of scenario of of deploying and being able to implement blue, green, all these different things that really help you deliver safer because we're automating everything we can to make sure that we have a quicker delivery system that we're testing as we do our delivery. And so feature flags can only help benefit that process. And so we'll get into that in a minute. I always like to ask a little bit about my guests and exactly how they kind of got started and where they came from and how they got here. And so I'd like to ask you that question, David, just to kind of get started and give people some context about yourself. How did you get here? Sure, way back at the beginning of my career. I was an engineer working on a force feedback dial. So you could program a motor to put effects on the dial and a BMW scout came by and saw it and that ended up being becoming the iDrive. If you know anything about BMW history. This was 20 years ago. And what I discovered was that I while I do love building things and I love being an engineer. I also love coming up with creative ways really to sell people on something. And so a lot of my career has been in some kind of solutions engineer or sales engineer role, but I mixed in a bunch of full-time development mostly 10 years ago. And then more recently I spent almost five years as a product manager and came back to solution engineering. So right today what I'm excited about is split. And I've been I've been with split for three and a half years now. Split finally has some really excellent integrations with Microsoft. So I'm hoping I can show those off today. Yeah, absolutely. That's why you're here. Absolutely. That's why you're here. And so the big thing that we're going to be talking about and there's actually some great documentation that we have on the Azure docs site. I should say the dot net website because dot net you can obviously or any language that you're writing in. You can go ahead and implement feature flags. And so feature flags are built upon conditional logic that control visibility of functionality for users at runtime. That's our definition, David. But I'm curious to split kind of have a way to define what feature flags are. Yeah, we do. I mean, there's there's a number of different approaches depending on if you're, for example, just putting a flag into your code for the first time to experiment with it in development or, you know, to today's topic of Azure DevOps integration, there are ways to define the flag with JSON right in the pipeline itself. So when your build goes out, it'll come with the right type of a feature flag attached. So and then there's API driven approaches and there's different ways to use the UI. There's a lot of different answers to that question. So wonderful. Well, if you'd like to get more information on feature flags and the way that split does them, you can head over to the split website. This is a great page on here. I enjoyed reading this to get some context setting on the way split looks at feature flags and how they're implemented. There's a lot of different ways of doing feature flags, whether you're doing them manually or using a third party to help you out through the process. And I know that it's a it's not a very crowded market. So the people who are building these tools, it's been great to kind of see that balance. Yeah, I think the big divide is there are all kinds of open source tools that are file based, right? And then there's a big leap, a gap to tools that are cloud driven that have some kind of cloud based aspect to how they deliver. And, you know, split, I think we have an ideal mix of decisions for architecture. There are obviously other products in the space, but but there are a few cloud driven architectures of any kind out there. So that list is short for sure. Yeah. Yeah, I mean, I know of like a maybe like one or two competitors of yours, but it seems it gets it's still a pretty niche market that gives people kind of an opportunity to see a better way to deliver and utilizing what are pretty sound DevOps practices of, you know, using flags to make a determination on whether or not a certain feature should be in a build. And when it's been in that build. How does it go through the pipeline process until you eventually have a ready to go deployment version of whichever your feature you're delivering. And I want to say hi to your dog. Yeah, I couldn't keep her out of the house today. Well, I mean, you know what that adds kind of like a reminder that we are for the most part most of us are working from home. We're living that that kind of remote life where dogs and kids and all that stuff kind of become part of the background when you're doing streaming and meetings and stuff like that. So it's no problem. I'm a dog owner myself. And I lucky enough she's in the other room. Okay, yeah, our Laila and you'll you'll see a picture of Laila I think a little bit later in this program but you know she's definitely a tapestry she is a beautiful dog. So, yeah, we love that's great. Put up with the market. Yes, so we've got about 45 minutes of time to go through learning about feature flags learning about split. And so I wanted to ask you a question first about feature flags and the first question is how do you implement them. Yeah, that's great. I actually, Jay and I spoke before this about how I have a Bob Ross style presentation for answering that question. So for those of you who don't know Bob Ross he was nicknamed the hippie painter he used to have a program on public television where he would take a blank sheet of canvas and he would look at you through the television and tell you, you can do this. And then proceed over the course of the next half hour or so to paint a beautiful landscape. And one of his key things, which I will repeat for myself is that it isn't about being perfect, you can make mistakes, right. The happy little cloud that he's so famous for painting may have had a gray lining to it that he worked around, you know. So what I'm going to do is, shall I just dive in Jay or. Absolutely. Go ahead and send us or go ahead and share your screen while you get a chance and just to give you all a view of Bob Ross and his hippie painting. I've got this one up here and sorry for those copyright owners. I'm not going to play the video but there's Bob making his painting. And I would imagine that what he's doing is he's doing his own version of feature flags where he's adding little bits of things at a time and then delivering. So let me bring up your screen and I'll give you a chance to start talking to us a little bit about how this all gets implemented. All right, so we work for a nonprofit that is aiming to drive the adoption of dogs. There are lots of dogs that need a good home and we're thinking about what's the best ad campaign to give people to drive them to click on these buttons donate and adopt right. One or one or the other of them right. So in this case we have a nice picture of a dog. This is in fact Laila, my dog, the day that she came home with us the day she was adopted. And underneath I have a little slogan just adopt the dog. But if you have feature flags, you can do more than this you can actually, you can develop a hypothesis you can say, I think that there are some other approaches some different pictures and different slogans that would get people to click to adopt. To click to donate more. So how can I use feature flags on a page like this and on the right I'm sure for those of you that have done any kind of HTML CSS development. This is the page that you're looking at right so here I've got a div with a banner that's the image of the dog, and then I have adopt the dog underneath. And then the buttons of course inside of another div so it's just a really super basic page there's a little bit of CSS at the top to make it prettier. But that's it so if we want to put a feature flag in here to start doing an experiment. How do we do it. So, to answer that question I'm going to go to split. And we're going to start a new feature flag. So I'm going to click to create a split. And we'll call this the Azure dog, or I guess God just for fun. Now, split has a notion of traffic heads for for lack of a longer description. This is a way that you can roll features out to things like you can see here, you can roll out to a city instead of a user, or you can roll out to a passenger if you're an airline or, or similar, or you can roll out to a tenant if you've got a multi tenant architecture. We're going to roll out to user. I'm going to click create now. The rest of this is optional. And by default split doesn't have any rules. This is where later on the Azure dot DevOps integration is going to come in it can supply a roll automatically. I'm just going to click OK to add rules now. And the rule that split creates by default is the go dark rule. This feature is turned totally off. So our Azure dog is switched off at this point. Alright, now to put it on the page. I can actually now go to help that split that I know, and I'm going to go to JavaScript is that's the SDK I'm working with we've got lots of other languages, and I can take the script right out of the page, come back to where I've got my page and their split included. We could proceed by reading the rest of the instructions on this page. But what I'm going to do that's kind of a Bob Ross move is I'm going to go back to where we created the split right here. And next to the kill switch. There's a drop down to look at syntax. So I'll click syntax. He put that up in size just a little bit. You bumped that up in size just a little bit just for our viewers. I want to make sure they can see everything. Oh yeah, what I can do is I can take it out of here and then make it real big. So I'm going to copy the JavaScript syntax out. I'll put it into it's better here right. Sure, yeah. Okay, we're going to put that right into our page. Okay, just like it came out. Now this has a built in if then else statement. We're not going to do that we're going to do something a little more exciting we're going to jazz up our mountain landscape a bit so I'm going to take that out. The only thing that I'm going to do is print out the treatment that split is bringing back. So we included split on the page. Then we use that syntax generator to get something that was perfect for our split. So now I'm going to come back to my dog. And if I reload the page, what do we expect console log to print out. There are two possible treatments on and off. Which one are we going to get. I'm going to go with on. All right, let's see. Oh, Jay, you're wrong. It's off. So why is it off? Well, it goes back to how we set up the split. Remember when we created the split, it defaulted it to off. If I switch this to on, for example, that cloud driven architecture pushes out the rule changes, and we can come back to the dog and now the treatment is on. But we haven't done the really fun part yet. What's the really fun part? So we wanted to actually experiment. Our hypothesis was that there may be other ad campaigns that are more effective. So how can we actually pull that off and split? If we come back to our split, we can use this section here called adding configurations to the treatments. And so what ultimately we're going to do is we're going to have Jason coming back to the app, but we're going to do it with this key value pair interface here that makes it a little bit easier to type. So I have the image URLs stored at the bottom of the page to kind of speed things up. So we're going to take the dog by the door. And we're going to put some text with that. We're going to say the dog by the door is bring me home, for example, right. And then for the off treatment. We'll come back to here. We'll do the dog by the couch. Okay. And we'll say image. And there's the image URL and text. This dog is chilling. All right. So I'm going to save the changes to the split here. And the first thing I'll show you is that now, if I swap, I can look and see what I did in JSON. And that knows how to return this with the feature flag. It's something that most, if not all feature flags cannot do, right? This is called dynamic config. And I can go back to, I'll go back to my syntax generator here. And the syntax generator looks a little different than it did before because now it's actually got a JSON payload. So I'm going to grab this version of the syntax and I'll come back to my page. And instead of the get treatment with the console log, I'm going to put in, oh, that doesn't look right. Let me make sure I copy this. There we go. All right. So that just gets me a handle. So how am I actually going to change the page? This is the one tricky part. If you're like me when you watch Bob Ross, you go, yeah, right, like I can do that. No, but you can do this. You can use the document object model. You can get an element by its ID, right? And the first element that we'll work with is the call to action. That's going to be the text, right? So I will do the inner HTML of the call to action. And now I can take that text from split. It comes right out of the parsed JSON. And I'll also do the image. We have that nice image URL. The image is ID banner. This is where the typing can get me, but we'll see if we can hack it today. So it's fun when you have to type for people live. I know how harrowing that can be. Yeah. Okay. So we've got, we've got them all set up. And right now the split is set for on. So when we refresh, we should expect to see a dog by the door. Let's let's see what we, we get. So I'll come bring my dog back. And I will refresh the page now and there's the dog by the door. How about that? Right. So that's, that's kind of exciting. And then just to illustrate, you know, we could have, we don't have to have just two treatments. We could have three treatments we want to if I switch back to the off treatment. What's going to happen is we're going to get the dog chilling. It's the picture is called dog on the couch, right? This dog is chilling, right? Looks very, very comfy. Now, let me point out something that may have blaze past as I was painting my way through this example. If you look at how we're handling the feature flag, the feature flag evaluation is right here, which was split happens locally. There's no network transaction to do that. I can explain that later. And then we, we actually repaint the page with result from it right using the document object model. Jay, do you see an if then else statement here? I don't. I don't. I think it's you've added these kinds of like, if you will includes that will utilize split empire, right? That's right. That's right. And so what this ends up meaning is that, you know, if you're a product owner, and you're trying to design a feature, you can use JSON like this to define the aspects of your feature that you want to maintain control over. And then the developers will just build the application, you know, and it can be in any language, right? They'll take this JSON. They'll build it according to your spec. And then if after the fact, you ever need to change the labels or adjust the colors or whatever it is that you spec in JSON is going to be open to you to change later. That's the power of split feature flags. So split is a cloud based service, I would imagine, as most are where you're actually keeping all these feature flag configurations. And my question is, what happens if they say the split cloud goes down? That's a great question. So let me pull up in our some architecture pictures and talk about this a little bit. Sure. So the first thing about split is that we pull the feature flags to the client. That's the first thing that our SDK does. And it gives you a bunch of different benefits. One benefit is that when you evaluate feature flags, if you're using private information about the customers, it never goes back to the split cloud. It gets evaluated locally. The other advantage to it is we're caching those rollout plans whenever they come down. So if you lose the network connection, the SDK actually can get ready against its cache and it can continue evaluating feature flags. And then a third benefit is that because the evaluations are local and the SDK is evaluating the flags without a network transaction, if your mobile device goes into a parking structure or behind a concrete wall and your customer loses their network connection momentarily, it's not going to affect your application from the perspective of the feature flags because we can do the evaluations without that network connection. Gotcha. Kind of a mouthful, but I got a little excited when you asked. So there's another question I have. We've talked about like why we would implement and when we would implement a feature flag. But a question I have next is when is it time to retire one of these feature flags? What if you've decided either you don't want that particular feature in production or you've already merged it and you don't need it to have, I guess, in your split anymore or in your code? Yeah, that's a great question. So you have some options. One of the most powerful ones is the Azure DevOps integration. And in particular, if we go back to the split, we'll look at this new onboarding split. You can either on the Azure side or on the split side associate your feature flag with a work item in Azure DevOps. So I'm following the link in and you can track your feature flags through their lifecycle using your tool. Split also has a rollout board for customers that aren't using a tool like this. But I would imagine that a Microsoft customer that's using Azure DevOps would like to track their splits. And for example, on the right here with the integration setup, you can actually look at which splits feature flags are associated with the work item, along with some of their details. And then there's the bidirectional click back. So if you're in Azure, you can click this link and it takes you back into looking at the feature flag and all of its settings and split. And there's a whole big page. I'm just going to go to it for one second. You can go to, it's a blog post from Dave Carroll last year. It was called get to know splits, new Azure DevOps integration. So there's a lot of detail on how it implements cross team visibility speed and safety as the default. If you want to check that out, you can head over to the split website and I'm sure it's in your press room section. Yeah, while we're in Azure, I think I'll take you to the pipelines to talk about automating splits as you do the releases. So here I have a pipeline that I started to set up. And if I want to look at the tasks associated with the pipeline, I can create a new task. And let's see here if I can get to the right. Edit pipeline. There we go. And split is in the Azure marketplace. So you can from your pipeline definition find split pretty easy just like this. And split comes with the default rule of all off. So we're assuming that most customers will want to push their, their splits dark. But this JSON is easily claimable from split. So if you have different rules like you want to do an AB test and set the treatments 5050 or if you want to do a canary release and push the feature out to 5%. It's easy to swap this JSON. And I actually can can show you how to do that. If we have time at the end, I'll come back to that. But but this is this lets you, you know, choose the split connection split has a notion of workspaces. Let's see if we can find our. It was called the Azure dog right. Oh wait, this is the. Prod default. That's what I want. That looks good. So if I add this, it puts the split task into the pipeline. So along with all the variables filled in from split for the workspace ID and the environment ID and so forth. Gotcha. I want to remind everybody also, while we're going through the show, one, if you've got questions or comments, use the chat that you are currently in. If you want to go to the learn TV website, there's a great chat service over on the right rail. You can just send your comments in that way or you have any questions. And then reminder that we are using a poll and we are asking are you currently using feature flags when developing your applications. So let us know because we just want to get some information on what you're up to as well. So we've got some of the implementation and early understanding, but you know, it's always important to be able to measure the things that you're you're implementing when it comes to any service there or any application that you're building or your infrastructure. You want to do some measurements to find out what exactly is going on how it's performing things like that. And so what do I need to measure a flag automatically. It's startlingly easy. So you need two things in order to get measurement like what you're looking at here. The first thing is called an impression. The impression gets generated by split automatically. So you basically don't have to do anything for that. You're just using the feature flag. The impression is the record that Bob came through at 5pm and we gave him the feature and Susan came in at 6pm and she got the control. So we know Bob is in the A group. Susan's in the B group when we actually go to calculate test results, right? So that's the first category. The second category is called events and events really are it's deliberately an open ended word for us because we take events from a lot of different sources. One event that could be that I could show you that's maybe the most basic is on our page we had the buttons to click and to adopt. We add a click handler on the page maybe like these here, right? We can actually use split to say track an event. So the adopt click for example. And I don't think you need to do anything more. There is some more sophistication that you can put in here, but it's as basic as that, right? And what that will do is teach split the behavior of the users so that when it gets ready to compare, it can come back and say, oh, you know, the dog on the couch got 25% more clicks to adopt than the dog that was by the door, right? So you have a scientific means of extracting the winning hypothesis, right? And from what I know you also have a number of SDKs that people can implement to support your software. Do you want to talk a little bit about like what languages are supported, what platforms that people can utilize? It's easy to go to help.split.io and on the left edge you'll find all the SDKs listed. They're organized by client and server side technologies. And this isn't all, we support more than this too. We have a RESTful API that gets used like for example by Comcast. The Roku channel is using our evaluator API it's called to do feature flag evaluation. All you need to do feature flags with the evaluator is an HTTP transaction. You do a get to return the feature flag. And of course the SDKs have lots of additional bells and whistles. Almost all of them are a very popular use. Sadly, Ruby has kind of died down in recent years. But otherwise I see almost virtually all of these I see on a regular basis. Very, very cool. So we've got about 25 minutes or so left. Which gives you an opportunity to show me what you were talking about before. You wanted to show me some other stuff. But I wanted to ask you if I'm using split, what's the cost look like? Because obviously you're not in the business of just creating something and not charging people for it. Do you want to talk a little bit about the cost that people would have when deploying the service? Yeah, sure. So what's interesting is that it's a little different from what a lot of people expect. The first part of it that's straightforward is the number of seats. So if you have developers and QA and product managers all working on the feature flags, and each of them has a login, that's one seat. Each of them has one seat. Interestingly, if you're a small enough shop that you really aren't going to use more than 10 seats, we have a free addition of split. You can make use of most of the split features without a cost if you've got fewer than 10 seats. And we don't limit the number of feature flags. We don't limit the volume that's coming from it. It's really a pretty rich free plan that we have because it's a good lead into a sale. People that use free for a year or more will come to us and say, now we're ready to grow. So that's good for them and that's good for split. Yeah, it's a lot like that freebie we were talking about before where you get the $200 in Azure credit. It's really just giving you a way to run through the service and make sure that it actually works for you. And then you can make a decision like have we grown to the point where it's time to actually pay for this thing. Exactly. And yeah, I think that's a pretty common way of introducing a software and services to different people and businesses that want to actually drive new features or whatever it is. So the next thing that I'd like to ask you a little bit about is who would be using feature flags? Yeah, I should finish out the licensing by adding there is a second aspect to it, which is the volume of users that you're rolling out the feature flags to. We call it monthly track keys. So, Jay, if you come through an app and we do 1220 200 feature flag evaluations for you, you still just count as one monthly track key, even though we did so many evaluations right. So it isn't about the number of times that you evaluate a feature flag it's about the number of unique users that you evaluate feature flags for that's the that's the volume based aspect to what we do. Can you you talk to me a little bit about the process of like controlled rollout and what that means. Yeah, sure. So I mean control rollout. Most of the time people are talking about environments when they talk about control rollout. So let's come back to split for a moment. I get to shape my environments. I have environments for dev I have environments for production you can see I've got regional production environments in this case, the EU US and Canada I was showing that for a customer. Each of the environments it's it's part of the same feature flag, but like in this environment the Canada environment. I don't have any rules set I haven't done anything yet. So you copy rules from a development environment. And now whatever rules were set up in development now become the rules for this environment right. So you would what a what most customers will do for controlled release is they'll start with one environment and then they'll roll across environments. And beyond that, maybe we, Jay, when you ask about controlled release for you asking more about rolling out the feature flag in terms of canary release and things like that. Yeah, yeah. Okay, maybe I answered the wrong question. Yeah, I think you did. I'm curious a little bit more about like who who's using or managing and deploying is this something that's really only geared for developers is there some sort of operations play into this where you're able to kind of see if one of these features is doing some sort of like degradation to services. Yeah, well what we do is, you know, by default, people can work on an environment without unfettered right. But if you want to lock down environments. What you can do is in our settings here, we can go to that that Canada production environment that I was just looking at. So here instead of allowing anyone to edit, you could just restrict to a particular set of groups or users who can edit. But we also have this feature called approval flows, where you can restrict the approval of the feature to a particular user or group of users So this this allows a product manager, for example, to make changes to a feature flag with the knowledge that somebody senior, maybe an engineering will look at their changes before they get they get fully approved. So, got you, got you, got you. So we've got a little less than 20 minutes left. And I know you said that there was another feature you'd like to show me. And I'd love to take a look at what else you've got for me. I want to figure, give a controlled release answer for you as well I mean split definitely can do some fancy stuff with randomizing the treatments out to a user base so on the left I have sample user so some of them got read the off treatment some of them got blue. You can see these targeting rules that are set up so about roles the product manager might come in here and say, I want to schedule this to go 5% at this date right and then go ramp up to 50% at this later date. So those all those controls are all available here. You can even identify users by their specific identifier, or you can bring in a group of same employees you might do this if you were testing in production. You let the employees smoke test the feature before it goes out to a wider audience. There's a there's a lot of goodness here in terms of that controlled release. What would you say are some some challenges of implementing feature flags and getting these kind of part of your software development lifecycle. Well, I think the what we've seen is that shops that are do it best adopt a standard that new features go out under flag. There's not debate about this should get a feature flag or that should get a feature flag there's just a consistent policy that new features go out under flag right. If you have all the new features under flag, then the something like this rollout board becomes especially useful because you can track those features across their statuses right. And, and ultimately the popular topic I'm managing flags is like how to erase them like how to retire them. And this is a great way to do that you can see either you know in the rollout board or an Azure DevOps you can see when the flag is ready for retirement and take it out. Sounds good. You know, I went through your your documentation around feature flag implementation, and it mentioned something that I thought was interesting. It's a term called flag management sprawl. And I was curious if you knew a little bit more that you could explain to people about like some of the issues that can lead to this, like sprawl flag management sprawl. Well, if you're pushing out every feature under flag there's certainly the opportunity for you to end up with a sprawl situation. And that's why it's important to have a life cycle for the flag so that you know one one really basic thing you can do a split that I think is is especially useful. It has this notion of tagging so on my new onboarding split here. I've tagged tagged it for cleanup fourth quarter last year right. It's past its expiration date. I can search for those tags, just by this this little filter here I can take the tag out and say, show me the flags that are are ready for cleanup and it will point point out the flags to me that I need to take out so. So there's there's the rollout boards there's integration with Azure. There's an environment dashboard, which also automatically keeps track by environment of the different states in the system. So you can find flags that are not modified recently or are no longer receiving traffic and then again take those out those are all different techniques for combating feature flags for all. So how does like testing in production come into play when using feature flags specifically when deploying with split. Yeah, actually this this is a. I went over it quickly but I'll come back to it. I have in this example here, the ability to show what testing and production looks like so I'll switch off the 5050 split. And we'll go back to a situation where I think everything's going to be turned off again right. Testing and production is usually done with with our whitelisting where you identify the user these are usually be user IDs right. Or employee IDs or whatever it is that you're you're flagging for this. So if I turn on just those maybe I'll switch on the employees to when I save the changes that at the left you'll see that everybody's still getting off. Except for the users that I tagged for testing and production right. Gotcha. And so that'll eventually lead you to be able to do say gradual rollout. And then you can retire the actual flag. Yeah, one of the fancier things we do is we have API for these segments. So let me see if I can pull this up quickly. You can let users decide if they want to be in a feature they can actually choose themselves in or out. So I think I have this, this page here. So, if for example, Jay you decide that you want to be in the beta program, you read the terms and conditions. I'll come over here I think I've got it in my beta users. There you go. So there's Edna, Josh, a bunch of other keys here. If I click join, what just happened is Jay became a beta user. Yay, just like that Jay. You're in. Oh boy. So you opted in to a segment which in split terms is like, it's like a set or a list of users, right. You can see that this set has an exception in it, right. My eyes are counting right right now. And so any features that are beta features will now be switched on for you. You could come in here and this is just a sample that you could turn on and off features and say I want this one. I don't want that one. Split would let you administer all that with these with these segments. So it's another powerful way to adjust the feature. Sounds good. Well we've got a little bit more than 10 minutes left in the show. And I'd love you to be able to show me anything else that you think would be definitely helping our viewers implement feature flags and specifically do them with split. Well, I did prepare. I have an example of split in an Azure function. I thought there might be great. Yeah, some people that like that. You know, we don't have this. I can show something else as well. But, but this is Azure functions are really. Really important and they are a service that helps people deploy code faster without having to consider a huge infrastructure investment. And having people doing that you can just create your triggers and use as you need. As you, as you say, Jay, well put. So the Azure function here is just using the split SDK to look up a couple of flags. One of the flags is a multivariate flag that has red, green, blue treatments to it. And what I'm going to do is I'm going to the input to the program is a name. Jay, you're, you're the guinea pig here. I can, I could have put in that a long time ago, huh? Run. Let's see what happens. It should talk to the split cloud and comes out that he looks like you've got the blues, Jay. Oh boy. Blue Jay. I'm a Yankee, but I'll take it either way. All right, all right. So, yeah. And in terms of what's actually going on here, we start by creating a split factory with a unique key. And then we use that, that factory to create a client. So there's a, in the case of, of dot net, there's a block until ready. And this is where the splits feature flags get downloaded. Right. On the client side, it looks a little different. There's a callback. We did earlier in this, in this program, when I set up the dogs, we were using a callback from the client side. So slightly different, but same idea. And then down below get treatment gets a feature flag for D Martin in the new onboarding one. That's when we've been flipping around. And then we grab a treatment for D Martin from the multivariate demo. And then of course we're taking the Jay's name from the query, printing this out. So there's not a whole lot of complicated stuff going on here. And I guess that's, that's the whole point. There is a, an interesting opportunity with dot net to integrate a cache. So instead of talking to the split CDN to get the feature flags, you can talk to the cache. The, the, this serverless function could use the cache instead. And that gives you a big performance boost on cold starts. So if, if there's an audience member that's interested in starting with split serverless, we should get together and make sure that you get set up with that cash. No, sounds good. So we've taken a look at how to use split alongside an Azure function. And I was curious, is there some reporting that goes back to the split website from here when we actually have implemented and deployed? I'm curious a little bit about just the reporting part. Yeah. So the impressions go back to split. So we have a little data hub here where you can listen for impressions or events. I was talking about that earlier, but let's set up to listen for impressions. So if I set up for impressions and I come back to my boxes that I've got here, we should be able to generate some impressions pretty quickly. The applications will report asynchronously in bulk impressions back to split. So that's so that we can do the experimentation, right? So that we can finally produce the results that people are looking for. So catch. All right. Well, we've got a couple minutes left. And I want to be able to give you the ability to just tell people a little bit more about where they can go to get started and how they can reach out if they actually want to talk to you or someone else about using split. Yeah, that's great. So a very gratifying best to remember is help.split.io. I went by this earlier today, but this is, it has a getting started link that will tutor you through initial steps. It has all the SDK links on the side. If you're playing with Azure, you'll discover that in the integration section, there's instructions for setting up Azure DevOps the way that I did for the demo today. So this is a great, rich place for lots of good information. And then as far as, you know, questions go, my email address is, let's see if I can pop it up meaningfully this way. David got Martin at split.io. I'll make that a little bit bigger. And I've also actually, I've saved it as a banner. So it is in the chat. And if you are wanting it right there in the video, you can see David at Martin at split.io. Very cool. Well, we're running toward the end of things. And I just wanted to say thank you very much for being part of this. And do you have any like things that you like to close with? Yeah, I'll close this way. Microsoft has an employee named Ronnie Cahabi who's very high level in data science. And his team has pointed out years ago that 80% of most feature development results in neutral or negative impact. Like people's best ideas about what to do next turn out a lot of the time and what to do next. So this is where split can really be helpful because we can measure those ideas as they go out. This is like a unit test in production for your behavior, the behavior of your users. You can watch them on these guardrails. You can do low level stuff like errors. You can do high level stuff like funnels. It's all going to make it much easier if you adopt a total solution instead of just feature flagging. Gotcha. So since we're heading toward the end of time, I wanted to show everybody the results of our poll. And it's 6040 with a yes. So more and more people are implementing feature flags. Also want to remind you on the right side, we've got lots of docs for today's show. If you're watching on YouTube, you want to go into the description section. There is a bunch of links within there, specifically taking you over to the split website. So you go to split.io, check out more about their product. If you want to learn a little bit more about Azure DevOps and Azure DevOps services, there's the Azure DevOps page. Let me share. I've got the short link for you, cda.ms slash 3M as in Mary 6. And if you wanted to look at the documentation associated with Azure DevOps, and there is a ton of it, you can go over to cda.ms, 3M7. So that's really it for today, David. I know that you're starting to get some colder weather out there in Austin, Texas. And I want to hope that you and your family stay warm, healthy, and happy. Is there a place online other than the email people can reach you, LinkedIn, something like that? I'm not on... Well, I am on LinkedIn. If you go for David Brook-Martin, like you see here, you'd probably find me. Otherwise, there's like a million David Martins out there. Oh my God. But I'm not on most of the social networks. Gotcha, gotcha. All right. Well, that's pretty much it for us today. I'll be back next week and we're going to be talking about Azure static web apps. There's a lot of new features that you can start using some stuff like new authentication methodologies. Some new features as far as going enterprise with it. So if you want to learn more about creating those full stack applications, tune in next week, same bat time, same bat channel. You know what? David. I do have one social network. Sure. It's unsplashed, if you've ever heard of that. I've got a bunch of photographs up for people to use freely. So if you want to come find me on Unsplash, you can search for David Brooke Martin in Unsplash and you'll find me. Very cool. Well, you know, I think that's about it. Why don't we, before I hit the video to close us out, why don't we give everybody a big wave goodbye. Thank you so much for being part of this, David. Give them all a good goodbye. Thank you. Very cool. All right, everybody, until next time, take care of one another and we'll see you. Make sure when you deploy that it goes green. I have to point this way. Thanks, Jay. Thank you, David. We'll see you next time. Take care.