It's been around 10 years that I'm building applications, and I used to get frustrated by not being able to move as fast as I wanted regarding deploying code that I write daily.

Having worked using old-school workflows like Gitflow or feature branches, it happened that sometimes, the code I wrote was finally visible to the end user months after the fact.

At some points, the following questions started to haunt me:

• "How long does it take to see your code changes in production"?

• "How fast can you get feedback from the users"?

• "How fast can you revert changes when a critical bug occurs"?
  And the list goes on.

So what could I do to improve the situation and not feel frustrated continuously?

The answer was: shifting workflow and using the right tool for the right job. By shifting from a "feature-based" approach to a more "code-based" approach, it became possible to deploy code multiple times a day. And this is the beauty: it's okay to deploy small pieces of code even if the associated feature is not finished yet.

We deploy code, but we release features. The idea is to deploy code many times until it finally creates a whole running feature.

"But wait, how do you accept showing unfinished features to your users?!"

You don't, you guard your unfinished feature with feature flags.

Using feature flags in a codebase is as simple as adding a conditional statement. For context, people have been using environment variables for this use case for years.

Let's think of it for a second: using environment variables means that when you want to deploy your feature, you need to rebuild it with the new environment variable value and to re-deploy it. Depending on your application it may take time.

What if instead, the value of the condition came from a remote service at runtime? It means that its value could change over time without the need for a whole build and deployment of the application.

Let's push this even further: since the condition is on a value that can change over time without re-deploying, it opens the door for a lot of great features:

• Rollout / Rollback at any moment

• Time-based rollout (activate the feature at a given date)

• Progressive rollout (only a % of the audience has access to the feature)

• Field-based rollout (using email, id, etc..., practical to create Canary & Beta user groups)

• A/B testing (a feature flag can have multiple values and so)

• A huge range of analytics and AI application for understanding the audience activity

This is why Progressively exists. Make sure to give it a try and give feedbacks :)