Software development can be challenging, but releasing new features shouldn't be. A feature deployment process can be time-consuming and error-prone without a proper feature flagging system. To me, it should be a fundamental part of the developer's toolbox because it lowers the risk of bugs and complications.
Feature flags benefit our continuous integration and continuous deployment (CI/CD) workflows. As developers, we can quickly roll out and test new features without re-deploying or changing the application's code. Due to its simplicity, feature flagging can be incorporated into both new and existing applications. Let me walk you through how to use feature flags in a Flask application to help you better understand this concept.
In a world where users demand fast, quality software, it is our job as developers to provide them with exactly that. So, what do you do when users need your app to run continuously, you need to add a new feature, but you can’t afford the downtime frequently associated with redeployment? The answer is simple - you use feature flags!
Feature Flags are mechanisms that allow developers to enable or disable application features without having to deploy the code. Simply put, they are variables whose values can be changed remotely, without having to touch the code again. It makes integrating new features and customizing user experience simpler than ever. It’s not only easy to use but also easy to integrate into your code, whether you are starting from scratch or integrating into an already existing app.
We live in a world overflowing with information, where we’re connected and online almost every single day. Informational overload is a real thing, and we should all be aware enough not to fall victim to this behavioral pattern loop.
To-do lists are a real "Hail Mary" in today’s clickbait-centric and attention-grabbing world, so I figured that it’d be fun for us to build our very own to-do app from scratch, using Ionic and ConfigCat's feature flags.
Feature Flagging is a powerful technique that gives businesses and organizations granular control over features by providing the ability to scope these features to a specific segment of users.
Feature flags are helpful for many reasons - one of which is they allow organizations and engineering teams in a multi-tenant software application to limit access to certain features by mapping them to the various tenants in the application or organization.
I enjoy hearing stories about how a company started and what the founders went through. For that reason, I interviewed a founding member of ConfigCat, Zoltan, to give us a glimpse into what went on behind the scenes.
Feature flags (aka. feature toggles) are becoming increasingly relevant in software development as they provide the ability to toggle features on or off in production, perform a gradual rollout of features and enable A/B testing experiments.
However, an often overlooked part of this feature flagging technique is that it introduces complexity and has inherent risks when said complexity isn't properly managed. As you're using more and more feature flags within your organization, it's important to understand that some of these flags are meant to last only for a short period and should, therefore, be removed from your codebase.
As a Software Developer, a feature flag management system gives me control and confidence when it comes to rolling out new features. I like that feature flagging offers this level of control as well as the ease with which it integrates into my development workflows.
Using specialized tools is beneficial. However, we often keep flicking between screens, making it easy to lose focus on what matters. But, if your tools integrate, that problem becomes obsolete.
I'm taking you around to learn how ConfigCat and Jira can work together to streamline your development process.
As developers, we spend countless hours building new features and having them pass through rigorous QA tests. However, despite experience and all preparations made, there's always that dreaded feeling you get in the pit of your stomach when you know it's time for deployment. What if something goes wrong in production and your feature doesn't function as expected?