{
  "id": 4875376,
  "title": "Deploying code and releasing a feature are two different days",
  "url": "https://urgent.news/2026/09/01/deploying-code-and-releasing-a-feature-are-two-different-days",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-01T14:37:07.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/goodbarber/deploying-code-and-releasing-a-feature-are-two-different-days-301n"
  },
  "original_language": "en",
  "account": "Deploying code and releasing a feature are two distinct processes. Code deployment occurs continuously, moving to production when it's ready, while feature releases involve planning, documentation, support, and sometimes pricing. This discrepancy led to the need for decoupling the two acts. The key to decoupling is the humble feature flag, a straightforward software object. Deploying code is an engineering task, while releasing a feature is a product decision. On a platform where every app shares an engine, conflating the two is impossible, as there's no option to ship to only some users when a deployment reaches everyone.\n\nFeature flags are nothing new; any team that ships continuously uses them. They're worth highlighting due to their role in illustrating the differing schedules of code and feature releases. A recently shipped feature spent weeks in production before it became available to users. One configuration value globally disabled the feature, affecting all users except those building it, who used it daily in real conditions. Once the launch day arrived, nothing was deployed. The code had been to production multiple times, while the feature went live just once. The separation ensures that the code's path to production and the feature's path to users never have to share a schedule, preventing either from rushing the other.\n\nWhen a feature is ready to launch, it advances through projects one by one. This natural granularity of the platform means that a feature starts with internal test projects, then moves to a few real projects, and finally becomes available to everyone. The platform never needed a feature-flag system; the architecture already included a switchboard for enabling features per project. Sometimes, the granularity gets very specific. In the codebase, there's a condition checking if the current project matches two hardcoded IDs, allowing those two projects access to features unavailable to others. This is the crudest form of a flag, simply doing what flags are meant to do.\n\nFlags and settings may look similar, but they're distinct, particularly for a platform like the one described. Feature flags and customer settings are the same plumbing, with the difference lying in the context. When a builder enables comments for their app, they're flipping a boolean that controls code already deployed, just like when a feature is released. The engine runs ahead of the product; code for a capability can be deployed fully while the capability doesn't yet exist as a product. The day it launches, what's new isn't the code itself but the configuration that now accommodates it.",
  "summary": "Everything we run ships continuously. The engine behind the apps, the back office our customers build in, the web products around them — code moves to production at the rhythm of engineering: when it's ready, it goes. Features don't work that way. A feature has a launch: a name, documentation, support people who know it exists, sometimes a price. That's a product decision, with its own calendar,…",
  "key_points": [
    "Deploying code is continuous, moving to production when ready",
    "Feature release involves planning, documentation, support",
    "Feature flags decouple code deployment from feature release"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}