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.
Developers are one of the most prone groups of people to sprout white hair before their time. This happens for a multitude of stress-related reasons, and not choosing a proper CI/CD DevOps platform surely plays a substantial role in this!
There's nothing more frustrating than writing up a thoughtful, intentional feature request to your favorite service provider and then not getting a response or subsequent feedback.
At ConfigCat, we understand the importance of feature requests because we know that our service becomes more successful when our customers are happy and their needs are met.
As a result, we keep track of each of our customers' feature requests to help us make informed product decisions and implement the features that matter most.
To keep an app or website functioning, a business may choose to roll out new features or make updates. If these updates or features are somehow shipped with bugs and are not well received by users, this may cause a decline in user engagement and can lead to revenue losses.
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.
Most companies believe they understand the customer, only to be shocked when their customers behave differently than what they expected, either intentionally or unintentionally. That's where A/B testing comes in to kick all these doubts and prevent the shock.
We’ll play around to see how A/B testing works with ConfigCat’s feature flag management service to take your experiments to the next level by giving you the ability to remotely control and configure your features without going back to the code.
Do you want to learn how to work with ConfigCat's feature toggles better and more efficiently? You've come to the right place! Let's take a look at the benefits of using some good practices when managing feature flags with ConfigCat.
This is a step-by-step guide on implementing an A/B testing scenario using ConfigCat and visualizing the results in a funnel with Amplitude. There is a working sample application on GitHub if you want to follow along.
Remix, the React-based full-stack framework for building server-rendered applications, has been generating a lot of buzz lately, especially since it was open-sourced. Remix is a dedicated Server-Side Rendering (SSR) framework for building web applications that are rendered on the server.