Zayyad Muhammad Sani

GitHub Actions is a great way to automate builds, tests, deployments, and other CI/CD tasks. But not every job needs to run on every push.

Sometimes you may want to skip a long-running test suite, pause a deployment, avoid unnecessary build minutes, or only deploy when a feature, release, or content update is ready. GitHub Actions already supports conditional jobs with if expressions, but those conditions usually live in your workflow file or depend on repository settings.

That works well for static rules. But when you want to control a workflow dynamically without editing YAML or manually changing GitHub environment variables, feature flags can give a cleaner option.

In this guide, we'll use ConfigCat feature flags in GitHub Actions to decide if the build and deploy jobs should run.

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.

Feature flags help teams release software with more control. You can roll out features gradually, target specific users, run safer production releases, and turn risky functionality off without redeploying your application.

But once feature flags become part of your release workflow, another question comes up: should your application code depend directly on one feature flag vendor's SDK?

That is where OpenFeature can help.

In this guide, we'll look at what OpenFeature is, how it works with ConfigCat, and how to use the ConfigCat OpenFeature Provider for Node.js in a simple Express API.

When talking to devs in the software development community about feature flags, a question that often comes up is, “Can’t I just use environment variables for that?” It's a fair question; both can influence how an app behaves. But under the hood, they serve very different purposes. Let's break it down.

Does it matter whether you evaluate feature flags on the backend or the frontend? The answer is yes. As you might have guessed, the frontend and backend are distinct components of software architecture—and the factors we consider when working with them, such as security and control, apply to feature flags as well.

In this article, we'll explore the pros and cons of backend and frontend feature flags and solutions to challenges you may face while working with them.

Suppose you come up with an idea to improve the conversion rates on your website. You could implement the idea and roll out the changes to all users. But what happens if the idea is only good on paper and fails in reality? In cases like this, conducting an A/B test is an excellent way to validate your idea.

In the upcoming sections, we'll learn how to set up an A/B test using ConfigCat feature flags and visualize the test's data in Google Analytics.

As you might have heard by now, the tech world is undergoing massive layoffs due to the looming recession. Big tech companies like Twitter, Meta, Google, and Amazon have all announced massive job cuts in the past few months. Software developers are on the receiving end in 2023, accounting for 20% of layoffs, according to data from workforce intelligence firm Revelio Labs.

Apart from the stress and anxiety it causes employees who were let go, layoffs can disrupt the rhythm of development teams and impact how projects move forward. The developers that survive layoffs are expected to keep everything running smoothly despite their smaller numbers. They'll have to explore strategies that will allow them to continue working efficiently and produce high-quality software without overworking themselves.

As the world increasingly becomes digital, we rely on software to solve problems that pop up in everyday life. However, because traditional software development is complex and time-consuming, there aren't enough software developers to meet the high demand for software products. No-code and low-code tools offer a solution to this problem by allowing people to create software and multimedia content and perform complex tasks without writing code.

Feature flags are becoming a prominent part of DevOps practices and for good reason. They allow you to turn features in your live application on or off without redeploying code. You might think that something so powerful would require some rocket science-level programming to implement, but you'd be surprised to know that, at their core, feature flags are booleans and if-then-else statements.

Okay, that's an oversimplification of things, but it's true. And while there are different ways of implementing feature flags, they all share this common core. That said, let's take a broader look at feature flags and their uses in modern software development.

Government agencies, with their strict security requirements, often face difficulties in fully embracing DevSecOps practices. Balancing the need for rapid feature releases with robust security measures poses a challenge. Feature flags offer a promising solution in this context. By seamlessly integrating into DevOps and DevSecOps pipelines, they can empower government agencies to effectively manage feature releases while maintaining high levels of security.