3 posts tagged with "CI/CD"

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.

GitOps is a framework that combines the practices of DevOps and Git and applies them to infrastructure management. It is not a tool or platform but a set of standards for managing IT infrastructure using Git. Within this realm, feature flags, like those from ConfigCat, can play a crucial role in streamlining workflows, managing releases, and enabling dynamic configurations.

Let’s dive into how ConfigCat and GitOps work together and why this combination is worth considering for your infrastructure and development processes.

Feature flags are a great way to control the release of new features in your software. They allow you to easily turn new features on or off without redeploying your code.

However, when implementing a feature flag in an application, we may want to customize its management after the initial release, i.e., schedule an incremental release/delivery strategy that is carried out automatically or schedule future changes to a flag's targeting rule that can take effect at specific time intervals.

For example:

• Activate a flag’s config by date and time. For instance, release a feature at noon on a Sunday afternoon.
• Gradually increase the discount value of an ongoing promotion at specific times of weekdays.
• Enable a feature only on weekends or on weekdays.
• Three days from today, turn on a feature for internal testing and enable it for public use a week later.