It has become very rare to develop software that does not require regular updates and patches. In fact, it's now the norm with the rise of agile software development. As a result, there are so many new updates to manage across our code making feature rollouts tedious and complex. Hence, turning towards a good feature flagging solution always saves the day.
As the world continues to change rapidly, software applications must be constantly updated. This forces software developers to release new features quickly. It is, however, a challenge to keep bugs and other software issues to a minimum. I have always found that feature flagging saves the day in these situations.
ConfigCat is proud to offer a robust, comprehensive feature flag service for software engineers to utilize safe trunk based development.
Companies must use the most up-to-date standards when developing their unique Information Security Management System (ISMS), as information security becomes significantly more difficult to protect the more an organization grows.
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.
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.
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?
In a traditional software development workflow, whenever there are updates or feature releases to be made, they are typically tied to a single major deployment to production. As a result, the frequency of feature delivery is slower and a lot riskier because there’s a lot more at stake with each deployment if things don't go as planned.
That is to say that releases should not be tied to deployments but rather, decoupled from them. Due to this reason, in a continuous delivery environment, it is considered best practice to decouple feature releases from deployments as it allows for more incremental releases.
Hence, understanding the concept of decoupling releases from deployment and how feature flags can make that possible is a key for any team.
Product managers are responsible for deciding what products to develop that align with the company's goals and also satisfy the needs of the customers. To be a successful product manager, you have to start by defining what a winning product looks like and iterate over it until it's right. To do so, you have to understand that at its core, a product is broken down into its features and quality of user experience.
However, when developing these features, even after thoroughly testing them in your development environment for potential bugs and issues that may negatively impact user experience, it may not always be sufficient to ensure a successful release to users.
