marzo 2019 – Luis Fraile

Some ideas on feature flags

30 marzo, 2019 Luis Fraile Deja un comentario

In the last weeks I have had several interesting conversations on feature flags, so I just wanted to do a little brain dump on my ideas/views on feature flags, this are my particular views at this moment, they can change :). Also, at this moment I have not heavly used them in production, I have tried them in production, but just in little scenarios, this is what I have learned and discussed with people who have been using the a lot.

First things first, for me feature flags is all about experimentation and testing hypothesis. I just use feature flags which are short lived so the code related to the flag itself is not so long inside the code, usually they are “if’s” or lambdas, so once tested the hypothesis I would clean them up, if hte hypothesis for a particular feature works, the rest of the code remains, if not, the rest of the code is cleaned. So when using a feature flag, it is important to track its life cycle so no “dead code” is left behind.

Next thing is almost obvious, if we are testing an experiment or a hypothesis, how and when we do know it worked or not?. We must work with business on this particular decisions and ask the stakeholders and team that question, this will lead us to something which is crucial, which metrics do we need to track for the feature we are experimenting, so be sure to track the usage and provide good metrics and a way to check them so you can take a decision about the feature. Probably taking the decision on which metrics and when to go ahead with the feature, it is harder than the implementation.

How we will handle the activation/deactivation? Some features can be even enabled/disabled by the users itselves, but not always, so we will have to decide how to do it, maybe we will enable them based on percentages, geolocation, or even automatically based on metrics, so when we go ahead with a feature flags system, be sure to know how are you going to be activating them during it’s life. For me this goes tight with the deployment of our application, so we must support enabling/disabling them not only via a UI or configuration files, but from outside systems which can interact with them and the system decided for rolling-out them with for example APIs or similar mechanism.

Last but not least, visibility, I started saying I prefer short lived flags, so how many flags we have in our code? which is the state (enabled/disabled) of them for our user base? keep in mind to keep them tracked in any mechanism you can provide so no “dead code” is left behind.

Just for you to check out a couple of feature flags systems, if you are on .NET Core you have this library, created by Xabaril Team, which is interesting and I know they are working on improve it. Also if you are looking for commercial products, probably Launch Darkly is one of the feature flags systems which is growing fast in use and capabilities.

Feel free to comment on this via comments or just reach me out in twitter.

Opinion: What and why YAML Azure Pipelines

9 marzo, 2019 Luis Fraile Deja un comentario

In the last days I have had several conversations around YAML Azure pipelines, some people asking me whya they should go from old “moving boxes” mode to YAML Azure Pipelines. So here goes my opinion on this, disclaimer, this is just and opinion post, don’t expect here instructions, but just my one (not event two) cent.

What are YAML pipelines? this is the new model for build pipelines, instead of using the visual designer, we go directly with configuration as code, using YAML language to define our build process. YAML has been around for some time, it is widely used for Docker, Kubernetes, and other build systems like Appveyor, so let’s just say it is an standarized way to define “things” in code. So it seems like the natural evolution to go for our builds, as more and more people and companies are going into this, making it a “natural” language to express. Is it difficult? for sure, it has it’s problems, usually around the spaces and tabbing issues, but more and more tools (you have plugins for VS Code and other tools in example) comes in our help.

Why YAML pipelines? Configuration as code. Our code evolves, and our build configuration usually evolves, not at the same pace for sure, but it evolves, so we must keep configuration tied to code, and which method could be better than represnting oour configuration as code?. So we end up storing our way to build right next to the code (another opinion: keep your code in the same repo as your YAML builds). So when we make changes to our structure code, adding or removing projects, new ways to build, the way to build is right with the code, in the case we need to build and older version, we will have the exact build configuration right with it, therefore we won’t have to make fancy things like recover and old version of the build from the definion history like with the “boxes” approach.

Is it ready for use? Yet I can agree sometimes the documentaion is not up to date, we should really go with the YAML builds, it is easy to start with. In any build definition we can get the YAML, clicking this button:

And also, for each of the tasks we have in and old model definition, we can also export YAML, so we can start learning from here:

I’m not saying you just go right away and modify all your existing builds and move them yo YAML, but next build definition you create, go with YAML and start using configuration as code.

Environment variables and Azure Pipelines

3 marzo, 2019 Luis Fraile Deja un comentario

Some days ago talking with Sergio Navarro (if you don’t follow him you should) he raised a question about setting environment variables in an Azure Pipeline so a container can use it in the build. The answer was easy, the great news are: all variables declared in an Azure Pipeline are “executed” (I couldn’t find a better word) as environment variables in the agent, and not only that, all environment variables in an agent can be retrieved as simple variables in the pipeline.

This is easier to understand with a very simple example, I’m using a Windows agent and just plain Powershell, but this can be adapted to Linux/Mac agents using bash, just one important thing to take care: Linux/MAc environment variables are case sensitive, Windows are not case sensitive.

We have this YAML build (hmmm the coloring on the second line is not correct):

It is just a simple build with one Powershell task, printing out the usual PATH environment variable, using the common syntax of Pipelines variables $(variable-name) and then printing out. We also configured the variables in the properties of the Azure Pipeline with a Demo variable:

When we run the build, we obtain the following output:

Check it out:

The first Write-Host, has printed out the PATH environment variable without any problem, and using it as it was a simple Pipeline variable.
The second Write-Host has printed out the content of the demo Pipeline variable but using it as a computer environment variable on the agent.

With this simple demo I hope it gets more clear, and you are ready to use this feature in your Azure Pipelines.