Build
Build metadata for version-aware feature management across applications and services.
Build contexts use these attributes:
| Attribute | Type | Source | Example | Private | Notes |
|---|---|---|---|---|---|
| key | String | Composite | api-orders-2.5.0 | FALSE | Service/App ID + Version |
| id | String | Build Configuration | api-orders | FALSE | Unique identifier for the service/app |
| name | String | Build Configuration | Order API | FALSE | Human-friendly name |
| version | String | Build Metadata | 2.5.0 | FALSE | Build version (semantic version) |
| versionName | String | Build Metadata | 2.5 | FALSE | Human-friendly version name |
| buildDate | Number | Build Metadata | 1640995200000 | FALSE | Unix timestamp when build was created |
| commit | String | Git Metadata | a1b2c3d | FALSE | Git commit SHA (short or full) |
Implementation example
Implement a build context like this:
const buildContext = {
kind: "build",
key: `${SERVICE_ID}-${VERSION}`,
id: process.env.SERVICE_ID,
name: "Order API",
version: process.env.VERSION,
versionName: "2.5",
buildDate: parseInt(process.env.BUILD_TIMESTAMP),
commit: process.env.GIT_COMMIT
};
Use cases
Disable features on known bad builds
Use this when you quickly disable features on buggy releases. For example, version 2.5.0 has a critical bug. Disable the problematic feature only for that version while users update.
Application-level configuration and customization
Use this when different applications in your ecosystem need different feature sets. For example, enable advanced analytics in the admin portal. Do not enable it in the customer-facing app.
Export metrics to determine when to sunset legacy behavior
Use this when you plan to remove old code paths. Export context metrics to understand what application versions are still in use. This helps you decide when to drop support for older versions.
Coordinate microservice deployments
Use this when you roll out features that require specific service versions. For example, enable a new API endpoint only when both frontend and backend deploy compatible versions.
Target by git commit
Use this when you enable or disable features for specific code commits. For example, a regression occurs in commit a1b2c3d. Disable the problematic feature only for that commit while you prepare a fix.