Thursday's Matter is a virtual meetup on the topics that truly matter to today's developers.
Join us Thursdays when we'll be joined by an expert from around the globe for a 40 minute talk followed by a Q&A session.
Each session will explore topics such as functional languages, mobile development, agile methodologies and machine learning.
Learn more at skillsmatter.com/thursdays
So let's start today. We are going to well, my name is Christian. As Alison said, I'm supportive person at a brief introduction just of Codrance in 1 minute to let you know who we are and why I'm here. Codrance is a consultancy. We are a person. We build software for our clients. We help developers to get better their graph through. Let me just remove this from my screen. We deliver and we help others to get better with training, with coaching and with mentoring. And we help companies get better at delivering software. Our main four pillars are modernization and delivery expertise and strategic and advice. And we are here because we born from the craft community of London and we like to share what we have been learning during all these years back to the community. And that's why I'm here and I won't bother you more with selling my company. You will see said that before. I will encourage you to throw any questions in the chat and let's get fun with feature flags with GitHub. I will be watching my screen that is in front of me. Sorry if I give you my site, but I will be on that screen. So what is continuous delivery? What are feature flags? Why are we here and what is going to happen today? So continuous delivery is a short cycle creation. Let me restart. Continuous delivery strategy is a way to create software based on short cycles of creation, where code changes are prepared for release. Following several steps, you can see them in the graph we develop. We build with test, we deploy and we monitor them. In these cycles, we ensure to have enough confidence. So each release is reliable at any time and this release is automatically deployed without any manual steps. This is a really important thing. We don't want to be changing or doing manual deployments while we try to get a continuous delivery. This is maybe one of the highlights of this continuous delivery thing and we will aim to build, test and release our with a greater speed and frequency. This is also really important in the modern world that we are. We like to be really agile, really fast delivering features. And that's one of the big steps. So what do we want? We want to deliver better software and we want it continuously. You will be seeing a lot of jokes. So I will keep your attention high. So that's why you will see these kinds of things now that you know all what is continuous delivery strategy? Let's see what are the feature flags? Feature flags or toggles are a feature flag or a toggle? Sorry, is a switch that allows you to turn off on or off without any code changes after deployment. So let me rephrase it. A feature flag or at all is a switch that allows you to turn a feature on and off without any deployment. Okay, so this means that when you release a new version of your software. You are able to control this feature without the need of being of redeploying or any code changes. In a fewer words. It has a statement that you will be putting in your code and will be controlled from the outside. Which types of feature flags we have? We have business Logic feature Flux and Development feature Flux Business Logic feature flux are the ones that will help you deliver any feature that any stakeholder or the business requires. For example, if you are going to as you see in this small image, if you want to test part of your application, you will deliver the new feature with a new code and you will be turning it on or off with this feature flag. This helps you to deliver and to factor the new feature and also improve the management and the control you have on top of your new features. As we will see in the next slide, it gives you the power to run a B testing or Canary releases or others, and the second ones are development. Feature flags are used by developers to put code in production without the need to worry about if it works or not or if it's finished or not. So with that you don't destroy the delivery and the evolution of your code and you also won't have any long lived branches in your repositories. I will explain it also in the next slide. What I mean with this is to help in to the development of the features, right. And each one can be configured by user can be by environment by percentages or all of them at the same time or other strategies that depending on the service you will have some of them. You will be able to the final list of users that you will be enabling or disabling the feature. In some of them you can define increasing percentage of users. For example, the first week it will be delivered for 10% of the user, the second week for 30% and so on. So with that you can deliver features very targeted ones. Right. And what are the pros and cons of these feature flags? The main pro or what I think is the biggest one is that it gives you freedom. Well, you and all the team and all the stakeholders, the product owners or the US designers or other stakeholders that you may have to do a B testing to do Canary releases and to control the feature you are going to deliver. This is for me the main value that you will bring by adding features to your project. But we don't have to think only on this because there are others really good ones. You will have only one source code to maintain. You won't have three branches in your code with three different approaches of your feature at the same time they will be controlled by environment. This is a really good thing because then you will be able to test different approaches in different environments, production, testing or staging or reproduction or the ones you have. And also it has to improve the track based development is what I was saying before that you as a developer, you won't need to keep a branch leaving for two weeks. Let's say if it takes two weeks to create the new feature and you spend all these two weeks working in a branch and all your colleagues are working in the main branch. Once you need to go to the main branch, you will have a lot of collisions in your code. So with drunk based development, what you will aim is to put all your code in the master branch at any time. So for example, at the end of the day you will put audio code in your main branch, and if you put them behind a feature flag, you don't need to worry about if it's going to be displayed or not, but in the other side. We have also not that good things that, as I said, are more or less as a statement. So it means that you can fall the in technical depth in an increase of the technical depth because you will be adding in a lot of places inside your code. If else or feature flag management to be able to put this new code. And if you don't define a removable strategy, you will end up with a mess of feature flags and code inside your main source. That is not what we want, right. This set up or this event statement will also lead to a harder testable code because you will need to figure out how to mock or how to set this feature flux in your code to on or off to be able to test the different features you are going to deliver, and sometimes the escape folding you will need to add to the project. To be able to work with feature flux can be tedious or to maintain or to handle. These are also the main issue you will find right. Well, I will stop here before I think we have a question. So I will answer now because I think it's quite a lot of information until this point. So if there is any question about continuous delivery or feature flags, please throw them. I see a question here that is from Abdul Gramam. What do you mean by removal strategy? Removal strategy. For example, in this image that I have here in the screen, let's imagine that you created for each of the Gray boxes you see in the screen. You created a feature flag. So you have feature flag one feature flag, two feature flag, three feature flag four. So you have four of them and you have been adding them. Let's say for the last three months. So in the first month you are the first one. In the second month, you are the second one so on. When you arrive to the moment we are now, we will have a huge amount amount of feature flux that will be adding a lot of noise in your code. So you need to define when you are going to be removing this feature flux from your code, because if not, you will keep adding more and more and more and more feature flags, and you will have to handle a lot of them inside your code. So when you deliver a feature flag, you go, you test it. You, for example, define I will test it for one week, and after one week I will remove it from my code. So in your sprints you will have time or during your iterations in the features, you will have time to spend removing these feature flags and by removing it's not only in the code, but also in the management panel that I will explain later. I hope this answered your question and we have another one. Another question. So it says, are there any particular use cases that are specially suitable for using feature flags? That's a good question. I will go back to the types. So as I said here, maybe I didn't explain it very well. Sorry, I'm a bit nervous, so sometimes I talk a lot and I don't say anything. So my point here was that in any case that you need to control from the business, any feature that you want to put in production, it's a good moment to add feature flex, and in the moment your code is evolving super fast and you need to parallelize a lot of work. It's a good point. There are other use cases, but for me, the most important thing with feature flags is that they give you more agility and more elasticity in the way you create. And you put code into production. If you think into the waterfall approach of delivering feature, let's say that you need to create a new page and you spend one month creating this new page in your website. And after one month you put it in production and you have a ton of code to put in production. But if you try to do the approach with feature flags and you start putting them in small iterations and you think just about this small piece of code, you will end up by delivering smaller things, but faster. You won't need to wait until the end of the month to be able to put a feature plug into production, but you will put them in smaller pieces and be able to test it super fast. So for me, this will be the biggest use case. And also, as I said, for developers, is a really good option because it gives you the possibility to paralyze a lot of work at the same time and without worrying about if my code is the same as I have in production, because I will be pushing always to master and you will be always at the head of the repo. Right. So that will be my two approaches here. So if there are no other questions, I will continue with the explanation. The last thing I wanted to introduce you is that when you start putting in production or when you start thinking about putting in production or setting up your project for featured Flux, you will need to think about how you handle these flags and how do you provide these behaviors to your application. So the first thing we all can think about, right, is to have a file in your project that it will say if this let's say feature flag is enabled or not and you will use it as a configuration file. But then you will need to always update your code and to do a deployment to be able to change the state. Right. So for that is where the configuration servers enters into the game. Configuration servers are services that provide external configuration and abstraction of your configuration, and they provide an API that will be consumed by your application. To gather these configurations. So you will be able to remove from the logic from your file. Let's say that you have a file that is called feature flag. With all your requirements, you will put and move all this outside and then you will just have an Http client or whatever that will consume this API and you will use the result of this API. But to enable or disable the different features, there are a lot of them that have been working with lunchdarkley in the past. It's really powerful. It has a lot of configurations, like what I was saying before. For example, you can configure the delivery of the feature by percentages in an incremental percentage way, like first day 2%, 2nd day 3%. So then you can control this from your site. There are user listings, also the other one. It's really powerful and depending on the project, I will recommend it. I'm not paid by lunch directly. So take this as a recommendation. But then there is GitLab GitLab as you know, repository. Well, it's really powerful. Also, it has pipelines. It has a lot of the things you will be using in your daily basis, and it also provides a feature flag configuration server, and it's based in Unleash. Unleash is an open source configuration server that you can use also, and GitLab is on top of it. So I will be using this because it's free and for the demo, it's the best thing. So I will be showing you how it works in GitLab, how to set up and how to manage some of the configurations. So what we are going to do or what I'm going to do is I will be creating using View. I have a small project that I will show you. We will be different configurations of feature flags, and I will be introducing you two ways of handling them in view. One will be more manual and the other one will be based on a library that I was using in the past and I changed it a bit to work with GitLab and we will be implementing different strategies. I think it will be really enlightening example. So let's see. We'll be switching. Can you see my ID? Yes. Yes. Cool. We have a question. Solid name. Cool. Thank you. Okay. So I created a small application that I'm running in the background. That is this one that I'm showing you here application I have been using in my previous workshops. In the first one, I was testing it and the second one I was playing with server side versus client side rendering so you can check them in YouTube. But the main goal of this application is really easy to search images in the NSA NASA API. So you can see this. And what we are going to do is we are going to add a banner in the middle and we are going to play with the feature flux. So let's go back to the code here. I will show you the application. So the application has as you see the title and the search bar. The search bar is another component that has a loader. It has the Gallery component. So it's not a super big application, but it has some nested components. So it's quite okay to start with. So what I will do now is by adding my first approach. So I have the exercise prepared here. I will be just copy pasting this and now we will see what happens. So now we have a banner here. We have mask here watching his rocket, and what I have done to implement this is that I have a banner component that has two images. These two images are behind beef that will show or not one or the other image. If this feature flag enabled, it's true. It will display this one, and if it's false, it will display this second one. So the spasix PNG is the one when it's disabled, and if I enable it by default, we will see that it's no. Sorry, because I have plugged in. So if I put the value to true, I will see the other one. Right. So what we would like to do now is to apply a real feature flag to get this feature flag from the GitLab server and to be able to test that if this works or not. Right. So what I have done is by checking the API of GitLab. I'm doing two super straightforward things. One is fetching all the feature flags. I will be sharing this repository in the chat. If you want to check, I think I can share it now so you can check at the same time. I think I pushed sharing the correct one. So here you go. You can check this repository. I think I pushed the last version, but if you check the different commits. You will see the Volusion. I think it's the same. This copy paste thing that I'm doing from this, in fact, are the different commits. But just to be sure that I'm doing the correct thing, I'm copy pasting them. So as I was saying, we have two functions here. One is to fetch all the features. This will request the features from our server and it will pass on that we will need and it will store them in this all features value. And then we will have another function that will be called with a feature name and it will take all the features and it will tell us if it's enabled or not. Right. I think it's quite a straightforward. I don't think it's super. I think it's quite easy to understand. If you have any questions about the code, please send them. And then what I'm doing is this function is feature enabled? Well, I created a view plugin that is what you see here. This is a view plugin to inject it directly to the context. So this will be available all along the application. And what I'm doing then in my component is that I'm going to enable or disable the feature flag based on what I will have. I will request from Gidlab. And the last thing is that as you can see here at the very top of the plugin is that we have a host, we have an instant ID and we have also the environment. These are the three things that you will need to set up to be able to run the different tests in this application. You can put them inside an N file as I'm going to do. So I have all the values here and to get these values, I will show you now the first one is going to say the environment you are. In fact, you can use the node environment here instead of this one. But as I wanted to do it in life, the demo I made it like this. Then you will have your feature flag, host and your feature flag, and this will come from the I will mention that this shouldn't be in the repository because it's a token and it shouldn't be committed. So don't do it. And now what I to be able to see and to do that in your repository. If you go for example, you can see that I created also a pipeline. It's not super complicated, but it's just, for example, just with something. So you will be able to see if the pipeline is passing or not. And this step is where you after will be deploying your application, for example, to AWS or whatever you want, and then you will manage also from here your feature flocks. You can find them in under deployments. So here, as you can see, I don't have any feature plug right now and you can configure it from here. If you click this button here you will see your API URL, that is this one and the instance ID that is this one. If you want to change this instance ID, you just need to cancel or to reverse it here and you will need to change it in all your application. So what I made just before the meeting is to copy paste these values here. So as you can see and this one are the same as I have here. So with this I have my plugin set up. I have all my environment variable set up and I created the component. I added it to my code. I added the feature flag to my code, and now I'm going to test it. So what I'm going to do is to restart the server because as I added some environment variables, you will need to restart. And right now I don't see any changes. I have to see the old one. Right. So what I'm going to do now is I'm going to create a new feature flag that is going to be called banner. You can add a description just to let you know what this feature flag about. You can define the strategy you want. So you see there are some percentage roll out based on ideas, sessions, random percentage of users that you can determine in your application the user ID just so that we will see later or a user list. So you can create list of users. And also I will keep it right now for all the users. And also you can define environments right now. I don't have any environment, so I don't need to select it. But if I go to environments and I create a new environment, as I will call, for example, development. And now if I go back to the feature flag page and I try to add a new feature flag, I will be able to choose the environment right now. I will keep it for all the environments and all the users. So we created it as usage quite straightforward. And now by default I will keep it disabled and see if it's doing something. And as you can see, it's not doing anything. And now I will enable it and I will re load the page and you see that it's Loading the new one. So as you can see it's something really fast to do. I don't know why this shows like this, but anyway, but as you can see it's something really fast. So if I disable it and I go back to my application, I see it disabled. I'm not touching my code. I promise I don't have any other my code. It's in the same screen. So I'm doing it in life. And this is the power of feature flags. Right. So with this you will be able to give the power. For example, if you are doing a marketing campaign and you don't know which banner is going to work better, you will be giving this feature flag management panel to one of your stakeholders and just tell them, go there, enable and disable or put your strategy here and you will find the result in life. Okay. So I will go a bit faster now because I think I'm reading off time. I thought it was going to be faster. The second example I wanted to put is a bit more complicated. It's using plugin that is called okay. Thank you, Alison. It's a plugin that is called View unleash, but the module itself is not well prepared for unleash, but not for GitLab. So what I made is to copy it in the project and modify it a bit. It just changes a bit the way it does the request and the way it passes the strategies. It's just two things that I needed to change because it was not properly set up from this use case. Now let's see what's going to happen here. The difference between the first approach and the second approach is that now we will have Bux that is the store manager for Buick. And so I will need to go to do an install because this plugin list is using in Buick to store the feature flux. So what he's doing when you install this module? What is doing is fetching all the feature flags and storing them by committing them to the store. So it's more or less doing the same as I was doing in my plugin, but a bit more in a more modern and more robust way for this. Well, what I wanted to mention just here is the same is more or less the same. The code is more or less the same. But the only thing is that now we can manage the strategies. Now we will be able to apply different strategies. The strategies are something that you will need to take care in your code because each application is better mining themselves the user ID or others. In the case, I'm going to show you what I made it to. Using the what I'm going to do is changing this to a user ID. I'm going to be adding one user ID that I choose randomly and I will be applying it in my code, and I will be applying this strategy to be able to enable or disable. Does this one work or not? Let me know. I see that it was giving 404. So let me know if it's the correct one. Now, if not, I will be sharing it at the end. Sorry for the inconvenience. So what I was saying is that I'm going to enable the flag just for a user. What I'm going to do is to emulate the user login and I will take this user ID from the login and I will use it to check if I have the feature flag enabled or disabled. Right. So here the user with ID file is the strategy I defined. So in this line. It's where you will assume that you are logged in. Okay. I will check the permissions right after the explanation. What you will assume here is that you are logged in. So this hard coded email is the one you will retrieve from the user token or whatever you want to use for targeting your user. So this one is the same I'm going to add here. I'm also going to add it for another user. So let's see like this and for random one. So it's also going to be enabled for all the environments, but just for these users. Right. So I will remove the first one. So I will enable just for Christian Monoto and Randall, what I would like to see now is that I have the status of my flag is enabled, but for my user is disabled. So right now let me run the server. And right now what I will see is that it's not present the banner here. Okay. So I'm going to add my user now. So I will just say that it's now enabled for Christian Munoz and for random. And I will check again. So here you see that by targeting the proper user, I enabled the platform for this user. This is also really powerful, for example, for marketing. If you have a newsletter, for example, and you say if you want to receive news about Doc Coins or from Mask or whatever register here, you take this list and you put it in your feature flag list. And that's all right. So this will be one example. Let me check why this is not being displayed. Let me know if now you can access. Yeah. The last test I can do is for example. Now I have enabled it for all the users, but I will add just another environment that will be production, and I will enable my feature flag for my user, but just for production. Now I'm going to add it just to production. You can see that it says it's for two users on production. So now I have it disabled again. I will change it to development. That is the one I have in my application, and I should be seeing it if all works good. And if not, it's the demo effect, and we will let's see. No. Well, I don't know what's going on now, but in the previous code it was working. So you can check it in the previous quote, and I think it's all I will be answering. Now the questions I see. How do you manage duplicity of code or non use code of your feature Flux? Thank you, Dave. Well, the duplicity of the code and the non use code is what I was saying. In the contrast of using Flax, you will need to be reviewing or placing an amount of time, each sprint or each certain time during your development to remove all code. This should be agreed with people from product or with stakeholders. So for me, having a duplicate code is not an issue as long as you know that it's duplicated and as long as you know that this is going to be removed, so don't be afraid to duplicate code if it's for small amounts of period of time. Right. Because if not, you will need to be controlling a lot of adding a lot of parameters to your functions or a lot of configurations to your features to be able to not duplicate the code. Right. And if you want to do a test, as I was saying, for example, if you want to test Navy testing, sometimes it's better to go straight forward to the solution than thinking about the over engineering that you will need to do to keep the code as soon as possible. I agree that it's adding this duplication, but if you tackle it with a proper strategy of removal, it's completely fine. And the other question is, when do you decide and how do you remove the feature flags from your code base? Well, I think it's the same. I just mentioned. The decision is if it's a development feature, let's say in this case, let's say, for example, that I'm still developing this or I don't know. Let's say, for example, this imagine that you have this right. So you start developing your application here in day one and you end the day one and you are not done because you need to reach this point. Right. So this is the end of the call, and in the day one, you are just here. If you keep it as disabled and you just continue your development tomorrow, you will be able to put this in production without the need of creating a new branch. Worrying about if you have conflicts when you're going to merge to your main branch, you will need to take care of all these overhead that you will have if you start creating the branches. I'm not saying that this is the solution for all the cases, because sometimes you need to just start a big bunch of work and you need to create your own branches or your own separated code. And it's also true that this can if you are touching in this example, it's really easy because I'm just touching one file. But if you are touching a feature that goes from the start to the end, let's say that you are changing the colors or you are changing the login process, or you are changing your API, and it also impacts the front end. You will need to add these toggles all around your code, so this will add a lot of noise in your code, so you will need to put in balance. Right. If you really want to push for a feature flag in this case, or just create a branch and spend two days in finishing it. But it's good because then if you force yourself to put things into production. You will think how to not break your previous code. So you will need to be sure that what you are doing is actually well tested and put behind a feedback or a good test. Any other questions? By the way, can you access now to the repo? Yes. It looks like everyone can access it now. Cool. Okay. So I will stop sharing them. Well, thank you for the yes, two things more. I will share again. Sure. So, first of all, I was here. Thanks all for being here. Thanks for your questions. They were really good. I really enjoyed. I have to apologize because I was really nervous at the beginning. Then I think it went pretty well. And as Alison said, you can find me in LinkedIn or in Twitter. Reach me at any point. Send me any questions. Well, that will be all now. Yes, I'm done.