 My name is Leena. I'm going to talk about merge health and how can we How can we how can something like feature toggle help you to come out of it? So let's start with the story story of team X A team at a startup which got recently funded and because of that they got they got they were able to hire a lot of people quite a few people and and They are trying looking forward for a major release the first release after they got funded so a lot of eyes on to them and And the the team is excited because they are Because of one thing is because they are doing a major release after they got funded and There are a lot of importance for that and the second one is that their customers have been waiting for some of the major features Which they were not able to release because lack of people and now they are they are trying to revisit and then the entire team is very excited and They want to be very careful so They created small teams the so-called agile pizza team one pizza team and to make sure that they are and then they had continuous integration setup among each team and They had automated testing to make sure that they done there are no irrigation shoes and They were fine. They were committing to the future branches they continued like that and Then they started integrating because the release date is close and then they had time for integration and then And merging to the master and releasing and when that came came the situation was different They there were a lot of fights not fight with each other fight with fight was with with the code base Especially because they had a very long-living branches and they had to fix a lot of merge conflicts And that resulted in regression issues test fit started failing their conference started coming down Because they had a lot of confidence because of the automated test that that came down because they were They were not not sure what they were doing. They were just just fixing things and moving on and the team which were looking forward for the for the release and Then the bugs also came in which the which the the team which were looking for the for the release They they were trying to run away from that and then they definitely miss the deadline. That's that's for sure and Finally they made a release, but which which was very None of the team was happy So the investors were very curious. Okay. What is happening business team and the sales team. They were very very Furious, okay. Why in the in the world something like this happens and the team is totally demotivated and So I think most of you might be familiar with Such a such a situation not exactly the same situation But somewhat similar to the situation where the end-end type of our release takes a tremendous amount of time The until then the feature complete gets done, but never goes to production I think one one style or the other we all of us would have faced it in the past and So, let's see what went wrong with them And for us for first to analyze that first, let's look at What is continuous integration? This is this is the Explanation this this is what is written in Wikipedia. This is the this is what what this is how Wikipedia explains continuous integration I have highlighted the key terms over here That is it's a practice Of merging all developer working copies to a shared my main main line several times a day So what happened with team X was they never had a shared main line and they were not merging to that main line several times a day and that is where it went wrong and That is where the main line development come in came in the picture Tram in the in the the morning spoke about how do they how they do things at itsy where everyone commits to a main line and and this is this is this is one of the key thing for a Proper continuous integration setup. So mainland development is or trunk based development is where the entire team commits to a single branch which you call as master or trunk whatever name you you call it and and then that particular branch is ready for deploy at any moment of time and the continuous integration runs against that and it gives you the feedback that Okay, is it ready for for a deploy or not and that's a huge confidence boost for any team Because we have something in your friend and it tells you okay This is ready. Is there anything wrong and you don't have to do any other kind of merging or anything to make sure that you have a ready ready branch for a production release and But then the question arises, how do you handle incomplete features features which takes longer time? Are we expecting it to finish in a in a pace that that that that is not reasonable? And of course not and that is where feature toggle comes into picture feature toggles also many team calls it with different names feature flips feature switches Feature flags, etc. The concept is an ability for you to turn on or off or turn off a feature Depending on a criteria that criteria can be either the environment in which it runs or it can be a certain kind of thing like Like a certain set of users or certain the geographical location, etc So we'll talk about more in in detail about different types of feature toggles coming in the rest of the talk So this is how it looks like it's a Ruby code Of course, I know what you're thinking. We have if else That's that's an anti pattern, but it really works. So You have a check whether a certain flag is true then you do a certain kind of execution, otherwise you do something else and that is how a feature toggle works and you can do it through configuration files either Yaml files or property file, which depending upon what kind of framework or language you are you are using and Using that you can do or there are quite a few open source tools available across languages, which you can use for for feature toggles That depends. How do you want to take it forward? For example, rollout is a very very popular one in the Ruby world toggles is another one in the Java world and so on so forth so I picked some and put it over here and But I'm sure it is available in across all the languages and so usually Most of the teams at least in my experience The toggle starts off as release toggles a way to segregate your deployment from releases you are ready to deploy at any moment of time, but that doesn't mean that you are releasing and And that gives you gives you a confidence that okay And then how you can you always have the confidence that the feature which is not which is not ready either because it's incomplete or it requires certain acceptance from say some major stakeholders it is still it is the code is still there, but it's not you it's not open to the users and This allows another one that another facility that is that is you can if you want to push a quick Quick patch or a bug fix to the production what you can do is you can you can follow the same process You don't have to create another branch for that or merge with that and then it goes through the same code and then there is no question of Developer developers merging into a certain branch and then rebasing it and and so on so forth and another thing that that I have personally have seen is that you can keep the toggle until you get some kind of a confidence and Say you you push something to production your and then you see some unexpected behaviors in production Instead of rolling back the entire code Which is ideally the case that should happen but until you get to that level of maturity you can do what what you can do is you can turn off the feature and Deploy another one and then the production is taken care The the thing is that the feature is not available to user But it is much better than a situation where it affects 100% of the user because of because of Lord in the server Or some misbehaviors in the server. So that's another advantage that you get with it and There are there are a couple of other types of feature toggles Multiple people spoke about this Multiple talks one one such thing is called a B testing where you can Where you can open up the feature to a certain set of users depending upon a certain conditions such as Depending on and geography or say age group or so and so forth. So the difference between a release toggle and experiment toggles is that Experiment of experiment toggles are based on certain criteria Usually based on the based on the user's criteria Release toggle is usually based on the environment in which it runs usually in all preproduction environments, it will be turned off and In in in production environment the toggle will be turned off and so but that's a difference between Experimental toggle and and release toggle another and another Another technique that you can use is can really racing that also someone Some speakers spoke about it that is instead of Instead of opening up the use of feature features to the entire user base You can gradually open it to the users In the advantage that you get one is like the a bit testing where you can see or say Monitoring how users are using it tune it accordingly and and you can quickly run another experiment to see how People are using it now or you can decide or desired. Okay, what what next step to take take on that particular feature And another another week and releasing is used is to set test your architecture or your infrastructure So rather than opening up to the entire user base you can open up to a certain set of users and see how your system behaves and depending upon that you can tune and Optimize for further load and that's that's another advantage that you get by having feature toggles as a setup in your in your development process and The there is a third type of Toggles called obstacles obstacles is a way to manage your Manually manage your circuit breakers for example So these are Say for example, let's take a quick case of a shopping shopping site or an e-commerce site where you have recommendations See because of a unexpected failure in the system the recommendation engine is not behaving Is taking too much load on the system? It can be because of network failure or a hardware failure. So what you can do is you can turn off that feature until you completely restore the service and So for those kinds of things also, this is this comes under the circuit breakers when something doesn't doesn't Respond within a within a time you expect you break it and move on and And the feature toggles gives you the flexibility for that too And that is how that's how you can you can use feature toggles also So even though we started off the talk with with saying that okay How can you push incomplete features to production? These are added advantage that you get by having a set up for feature toggles so but like when when Prem spoke about the feature all in the morning many people were talking about how do you have handled the if else in your core and So that's a that's a side I'm going to talk about so every every practice or everything that you do has a pro and con So nothing nothing is perfect. So so likewise a feature toggle So this is an actual feature toggle that we had in our system This is not something I made up. So once we had since these many feature toggles people forgot to remove ideally feature toggle Has to be a short-living but that ideal situation doesn't happen all the time because of various reason so We sat and and deleted all the feature toggles You can imagine the accommodation and combination of fulfills that code might have had at that point of time. So So we sat and removed it So how do you handle it? This this is not much different from asking the question How do you how do you create less bucks or how do you create? How do you handle your technical debt? There is no gold There is nothing like okay, you do this do this do this this will happen and similarly feature toggle also So to manage that only one guideline I mean my experience which has worked is that Setting guideline for the expiry date for every toggle. So once you create it say that okay It has to be deleted by this time that can be a standard across Across the team or it can be depending upon certain condition depending upon the complexity of the feature And over a period of time what I've seen is that it it it matures in within the team. Okay, so Recently, I've read which this is something that I have not tried myself that Certain teams have created Builds build scripts which will fail if the feature toggle is beyond the expiry date You can go to that level but I've not tried that but that seems to be very good way in that way It is completely handled automatically But it requires some time for you to actually say okay What is expiry date? Is it two days? Is it one week or is it two weeks? So you experiment it and see usually if you give time, this is like test driven development or say Or say pair programming it takes time. So you you work with people Open converse converse openly and then I think almost all the time this kind of things take take will be taken care of a period of time and Another thing that I would like to emphasize is that I Started with T max which is a team within a company. So I'm not saying that this is the way to go in an open source world So open in GitHub workflow works perfectly fine in an open source world because there it is open You need some kind of a control with what kind of code goes into the code goes into the code base And that is because there is no there is no hiring mechanism so-called so and it requires that kind of a control and Versus that in the product team or where The importance should be given to the code going into the production and see how it behaves rather than making sure that you are taking care of The coding guidelines or the design principles The the the best feedback that you can get is by going going the code into the production and that and how users use it And if it doesn't make sense just remove it that's that's the best thing that that should be done rather than waiting for someone to review the code and approve it and you have tools like lending and So many other things that you can do to take care of automate that too and do automate Offload that process much earlier rather than later in the design later in the release cycle And have conversation within the within the team have understanding and among the team to say okay This is the kind of guidelines that you that you follow so and but just to emphasize I'm not talking about open source over here I'm talking about just teams which are working toward a product team Which is which where where it makes complete sense at least that is that is what I've seen it it works and just to summarize Have a proper continuous integration setup That is follow mainline development ever the word if every member in the team come is to the same same branch and The in what I've seen is that this is a first major step towards continuous delivery or continued deployment Without having a proper continuous integration setup It is not possible. It is very hard Maybe bordering on to impossible to have a proper continuous delivery or deployment setup closely followed by automation but this is a first step and Use feature toggle segregate deployment from releases use feature toggles for that Run Qt experiments within the production to see okay how users use the features and use feature toggles for that too and Set an expiry date so that the feature toggles doesn't become a technical debt and This is a regenerated Tmax they learn from their failure. They didn't give up and Now they are happy because they can see when their code goes into production and that makes them very very confident and very very accomplished and I think that's it. Yeah, just an emphasis on the on the references the first first link I've given I'll be sharing the slides the first reference. I've given An article in multiple site. It talks very in detail about Feature toggles, how do you manage it? What is the use of each types of feature toggle? So anyone who wants to start with feature toggles? I highly recommend you to read that couple of other blog posts that I've written and It's my contact Questions we have time for question. We have time for one question so Nice talk. How do you define like expiry time for a feature toggle? I didn't get that part So what we have used is that we use we have our The ticketing system or a project management system. So we add another card saying that okay We have to delete this feature toggle by this date You can have reminders or sometimes what we have done is that in the whiteboard you write Okay, this feature toggle has to be removed by the state and when you're having stand-ups or say any other meetings people get notified about that so That depends and then how long is is I mean I'm a consultant. So I have the standard answer. It depends You have to try out and see what what works you? Until you get the conference in the production So that's that's the way to get started over a period of time. I think you get you automatically Did that answer you