 Good evening everyone and welcome to India Light. Very, very happy to be here with Leena, who is one of my favourite presenters. I had the pleasure of attending a talk that she gave last year in Agile India 2019 on the expand contract pattern and I'm very, very, very happy to be here again as she talks about trunk-based independent feature toggles. And so, for those of you who don't know Leena, Leena is the CTO of our practice now, which is the easiest way to monetize your Zoom classes. She is an exceptional speaker at multiple conferences, a mentor and a dedicated person to know. So, without further ado, I'm going to hand the stage over to Leena. Thank you, Siddharth. It's my pleasure to be here at Agile Light conference. Thank you. So, thank you for all the recognition. This is the trend of your presentation, but this year is different. I hope that you come out of this type of situation soon. Thank you so much, Leena. It started with my talk. So, a few years back, I was at a conference where the speaker was talking about the advantages that they caught by moving to the next frame of the JavaScript. And it was about how they moved their current code base to that framework. But one of the things that caught my attention was this code that we wrote 100 lines of code in six months. And now the code is very localized. We can add more features now. We are happy with the current code base. One of the members from the audience asked a question, okay, it's good that we wrote 100 lines of code in six months. Is it released to the users? What the value they got? What the value business got from this shift from one framework rather? And the answer was surprising, at least not in a pleasant way, but it was slightly sad for me when he heard the response. He said, no, we have not released it yet. We'll be doing that in the next few weeks. We've been doing this in a branch. We'll keep on doing bug fixes and other feature development. Now, meaning to add those back to this and in the next few weeks, we'll be releasing it. This is not a made-up story. This actually happened. And the speaker is from a well-known, well-funded, Indian startup. And they have all the money in their hand. They have a big team, maybe even a dev option to call that team. But the sad part is that for six months, they've been writing code out of lazy. And that's really, really sad. And this is what maybe at the top of it, I mentioned in their book, the early handings with the software development book, like how much time it takes for you, for your team to push one line of code to production. And when we ask this, you know that you can see a range of responses to this, say from hour or minute to say months or say even years. This again, I'm not exaggerating. I have seen teams which take months to push maybe not one line of code, but even a small change to production because of various reasons. So coming back to, this is a typical last-minute problem. It gets built, but nothing gets out. Nothing goes out or nothing becomes useful to the users. And how do you do that for architecture? So one of the, going back to the problem that the speaker let him call as Billy, they'll be state-based. One of the techniques they could have used is this wonderful technical branch by abstraction. So instead of creating branches for your code, you create abstraction layers in your code so that it can continue to deliver. And abstraction is part of any language that you take and it's really natural to it. And instead of creating branches as part of your repository, you create abstractions in your code so that you can continue to maintain both old versions and new versions of code. So what happens is you write abstraction for the new, new abstraction for the existing one, route all your old code with that. When you start writing the new one, write another abstraction for the new one. And then start keep on adding new code to the new one and then route it to the new one. And once you have done that, they can do a code base to the new implementation killer of the old one. And that is the technique with branch by abstraction. And a similar technique you can use for database. This is called expand contract pattern that Siddhartha has mentioned at Spoken at Jail India last year about this. Where you keep both old schema and new schema and then expand it for both. And then once you are done with the migration, you collapse to the new implementation. And that's a very good technique and it's a low risk approach for making database changes. So basically, what this is, that's what it is. I think it's a good technique to have a new deployment but that is what makes your code travesting from the developer machine to the servers. You know, you know, in a reliable and sustainable and predictable manner. And for you to have a deployment pipeline of what you need is what we call is trend based development of the development and contents of integration. So continuous integration without transmit, the development doesn't make much sense because the idea of continuous integration is continuously that all the developers they push to a single branch and at least once in a day, everyone integrates that code. And that is the meaning of continuous integration not the kind of things that we saw with the previous thing where they were continuously isolating not continuously integrating. And so when you have continuous integration and when you have trend based development what about if there are features that you don't want to open up for every user or you want to go to say user access and stress or say you want to get confirmation from stakeholders before opening up to the end user base and that is where feature troubles comes into picture. So again, continuous delivery is about continuously deploying. It doesn't mean that you have to continuously release. Release is up to the business when they want to they should have the power to decide when to release. Should it release to the end user base should it release to a few users those kind of things has to be within the business and that is what continuous delivery enables but you cannot do that if you are not continuously deployed. So feature troubles are like troubles or switches where you depending upon a condition you decide whether to enable that feature on a certain environment or for a certain user. So it's like toggles and then this is a sample to be code and you can control it with say either as configuration files or as environment variables or even in database you can click those and depending upon those conditions what the value of the flag it decides what to do. There are different kinds of feature toggles and I'll explain in detail in the coming slides. So usually feature toggles are short lived. You use it for a certain purpose and then you remove that feature toggle. That is a usual case. There are unusual cases where you can use it for as a long running toggle but if there are too many it becomes very complicated because feature toggles it fails to the code. So the release toggle is one type of feature toggle. This is a most common one or most popular one where you can avoid you don't have to where you can control what is when it can be released and you can continue to deploy. So for example we are implementing the feature and then that we need to open it up only in staging environment, not in other environments because we want to test it with stakeholders or show them over the stakeholders or we want to test it with testing in detail in the staging environment you can keep it as a release toggle and then once you're comfortable remove that toggle and push it to production. You can keep that toggle for some time until you get comfortable that this is indeed working as expected. Usually these toggles are in the front end your database or any backend changes that you don't you don't toggle it with that. What is usually seen with the release toggle is that certain functionality is hidden from the UI on either on certain environments or to certain users. Next is experimental toggles. This is usually for every testing when you want to test different kinds of different versions of the app or you want to release this feature to say 1% of the users or say 20% of the users first and then increase that that is what is called a scanner. It can be releasing and this is useful. This is the first toggle for doing that and this is not just configuration it is the toggles are enabled to disable depending upon certain condition of the user say maybe it can be the region or it can be the type of user, how long the user has been in the system so on and so forth. This is also usually it is short lived because once you get a hang of what version works better then you implement that and release to all users and the last one is obstacles this is this is where it can be where toggles can be long living this is for designing for failure a good example of this is say you have let's take the example of Netflix we are browsing and we are looking at one one movie and then usually it gives you recommended recommendations for the one you are currently movie and if that is that may take a lot of if that has a imagine it is using a lot of algorithm to identify that and then that service is actually responding slower or you have external integration where you get a lot of data and then you are showing it and then that external external service is down so either you can turn off that completely or you can or you can use a shorter cache version of that whatever you got earlier so if you want to turn it off completely that has to be on dynamically done rather than deploying it and that is where you can use obstacles so depending upon certain conditions this is not responding within this time then turn off that or show something else instead of that so you may have to keep for longer and that's why obstacles are kept for longer this is usually for usually for making sure that your system doesn't fail because of a external dependence or a problem that you have with some other integration and every approach anything that you do has pros and cons and if you struggle it's not much different than that so this is an example from a code base that you wrote a few years ago many and you can imagine the kind of complexity that is added into the system because of different things and how do you fix it what is the easiest way to let's say the dollar to dollar question because there is no easy way to fix it other than saying that there are obstacles to go on to the minimum one technique that worked well when I was working with the teams is that we keep expired expiry date for each job like no job should be even for say more than 6 weeks or say a few days depending upon as a team what you decide and then in the power for the problems which are more than that and then making sure that we clean it up on time I've read an interesting article about about feature toggling and then that was mentioned that a team actually wrote a script automated script to believe toggles to fail the build if there are toggles which are living more than expiry date I never tried that but that was an interesting idea that I thought it's good to share so but expiring keeping it expiring those toggles deleting those toggles after a certain time is really worthwhile so to summarize optimize for flow don't write the code in your shell instead of that releasing it to your users definitely learn a lot and so you need when the developer says something is done it has to be released or it has to be deployed it is merged with your tongue and then it is deployed to all the environments as soon as possible and that can happen only if you're working in small patches slice it use techniques like branch by abstraction and expand contract pattern to slice it and then release it continuously and rather than working on a branch and then merge it back and deploy and see surprises build a lot of safeness automated test is definitely a safe net your monitoring and alerting production technology have a lot of alerting and monitoring mechanisms to make sure that you know before your customers nothing goes wrong and so that is very important these are a few books that I think I don't think any of these books are moving anyone in the industry but I thought I could give you a refer and these are some articles I will share that's it I think from my side