Skip to content

1. What is it, what is it for?

The mantra of an application is: - Take as little time as possible to go to production - Reduce risks in production - Have fast and reliable feedback from our users (Perform A/B Testing) - Easy and autonomous development for each functionality (feature) - Multitenant, my application is unique but behaves differently for some users than for others, but I don’t want to maintain 4 different codes with their deployments, etc…

All these objectives are raised by the “Continuous Integration” and “Continuous Deployment” concepts.

2. How have we been developing so far?

2.1 Continuous Integration

  • Branching: We use branching strategies that most of the time end up becoming a mess of merges, versioning, back and forth… I’m sure you know what I’m talking about.

Half the time, when we finish a feature, we see that it no longer fits with “master” and we have to go back and fix it.

The “Continuous Integration” that we talk about so many times in meetings is being completely ignored.

2.2 Continuous Deployment

  • Environments: Generally we have several environments to test (dev, preproduction, production), and although your code works in dev and preproduction, you must admit that nobody would put their hand in the fire because their code works in production… therefore, to what extent is that expense in environments so beneficial?

  • Deployments: The most cautious, as is normal, use canary and affinity strategies to test the impact of a new version in production environments. This is a costly process both in the deployment phase and in the impact monitoring process, since you must have well segmented in your monitoring tools such or which group of deployments (you multiply it).

3. What would be ideal, the Frankenstein!

The ideal: - A single code, where all that can coexist - Where I can deploy any new functionality or fix a bug at any time in an agile way, even finished and unfinished functionalities can coexist.

4. What is it, what is it for?

Feature flags are a software development technique that allows you to enable or disable features without deploying new code. This approach provides:

  • Deployment flexibility: Deploy code to production with features turned off, then enable them when ready
  • Risk mitigation: Quickly disable problematic features without rolling back entire deployments
  • A/B testing: Test different variations of features with different user segments
  • Gradual rollouts: Release features to a percentage of users to monitor impact
  • Development autonomy: Teams can work on features independently without blocking each other

5. Key Concepts

  • Flag: A boolean, numeric, or string value that determines feature behavior
  • Context: The execution context (user, environment, etc.) used to evaluate flag values
  • Segments: Rules that determine which flag value to return based on context
  • Targeting: Defining which users or contexts receive which feature variations

6. Benefits

  • Legibility: Clear separation between feature code and feature activation
  • Maintainability: Easy to manage and update feature states
  • Rollback: Instant rollback capability without code deployments
  • Homogeneity: Consistent flag evaluation across the application
  • Application health: Monitor feature impact in real-time