10 posts tagged with "canary release"

Vibe coding is genuinely changing how software gets shipped. It's not hard to see why: faster iterations, lower barrier to entry, more time in flow, and less time wrestling with boilerplate.

Production, on the other hand, doesn't care about your flow state.

You've probably been there: a feature that looked clean in every prompt, passed the automated tests, survived a quick review, and got merged without a second thought, only to silently misbehave for a slice of your users hours later. The AI didn't know about the edge case. You didn't catch it. And now you're debugging code you didn't quite write.

This doesn't mean vibe coding is the problem. It means AI-assisted development needs a production safety net. And what is one of the most practical safety nets for production features? Feature flags.

Would you like to catch bugs before your users do? If your answer is yes, then learning how to implement user targeting in your next feature release is essential. The core idea behind user targeting is to control who gets a new feature or experience.

In situations where you need to test a new feature with a smaller audience first, user targeting helps you learn from real users without putting the full release at risk.

Coming up, we'll discuss two ways to implement user targeting using ConfigCat: deterministic targeting, where you hand-pick exactly who gets the feature by name, email, company, or any other attribute you know about your users, and percentage targeting, where you define percentage groups and let users land consistently in the same experience every time.

When shipping new features, releasing them to all users at once can be risky. Even small bugs can affect thousands of users immediately. That's why modern teams rely on canary releases and feature flags to roll out changes gradually, monitor real-world performance, and reduce the risk of failure.

In this guide, you'll learn:

• What a canary release is
• How it works with feature flags
• A step-by-step rollout strategy using ConfigCat
• Best practices and common mistakes to avoid

In the ever-evolving landscape of software development, delivering high-quality software that meets user expectations is a formidable challenge. The journey from conceptualizing innovative features to their seamless integration into a live application involves careful consideration, testing, and risk management. One valuable tool that has emerged to address these challenges is the concept of dark launches. This strategic deployment technique allows development teams to introduce and test new software features with precision, unlocking controlled innovation and user-driven improvements. Let's further explore the concept of dark launches and what they offer to development teams.

The primary goal of software developers is to ensure user satisfaction with the features or updates they introduce. However, achieving this goal can be challenging without the right release strategy. The question often asked, then, is, "How can developers be certain that a new update or feature delivers optimal results to end users?"

Two strategies that can be employed to address this concern are staged rollouts and canary releases. These strategies can be implemented using feature flags, and in this article, we explore how ConfigCat, a popular feature flag provider, can be used to perform staged rollouts and canary releases.

Software development is a really challenging endeavor. A lot of time and energy has to go into making sure that customers like what you're building for them.

Many people make the mistake of thinking that product development mainly consists of coding. Developing a product (ideally) needs specialists, managers, tactics, and various tools. A good idea can indeed go a long way, but if you want to give your product the highest possible chance to penetrate the market, then you need to allocate all possible resources that you have available to throw at it.

Picture this: You’ve added a new feature to your software, linked it to a feature flag, and deployed it to production. Now, you’d like to enable this feature for a subset of your users to get their feedback before you take the leap and roll it out to everyone.

But who gets to see this new feature first? How do you choose the first user segment? How do you use feature flag rules to target them?

Good to know: Feature flags let you launch new features and change your software configuration without (re)deploying code.

Let’s look at some typical real-world examples of how you can do canary releases using ConfigCat.

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?

Building a modern application often involves building it as a microservice, which provides developers with more flexibility and agility in terms of deployment options. However, deployment can either be a joy or a nightmare, depending on the strategy used, whether it's deploying microservices, testing new features, updating a business logic, or releasing a new version entirely? With every code change pushed, comes the risk of potential failures, which could be as a result of bad code quality or unexpected bugs, and this can potentially disrupt the user's experience.

Hence, picking an efficient deployment strategy is key to mitigating these deployment risks and not having to constantly disrupt your user’s experience by going into downtimes or completely having to go offline whenever there is something to be deployed.

Let me tell you a story about the myth of the Friday Release. Newbie QA guy was finishing up his tasks on a Friday evening after hours. The office was quite empty at that time, only a few people left.