LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Developer usage
  • Naming convention
  • Feature flag lifecycle
  • Feature flag for applications

Was this helpful?

  1. Development

Feature Flags

PreviousAWS SecretsNextDocumentation Contributions

Last updated 1 year ago

Was this helpful?

Developer usage

If you want to introduce something behind a feature flag you can follow these steps:

  1. Ask someone from DevOps for invite to ConfigCat.

  2. Once you're in (https://app.configcat.com/) you can add your feature flag. The initial values should always be "On" in Dev and (probably always to start with) "Off" in Production and Staging.

  3. Make sure that the CONFIGCAT_SDK_KEY environment variable is exported in .env.secret in the root of the repository. You can fetch it by calling for example yarn get-secrets service-portal.

  4. Start using your flag by using the package @island.is/feature-flags.

Naming convention

When creating your feature flag, please try to have both the "Key for humans" and "key for programs" descriptive. If the feature flag will be used by a single service, make sure that at least the human key contains the service name. Adding a clear description will also help others knowing what your new flag does.

Example: Your service name is "my-awesome-service" and you're introducing a feature flag called "show-content". The key for humans could be "My awesome service: Show content" and the key for programs could be "myAwesomeServiceShowContent" (Hint: The UI generates the program key automatically from the human key)

Feature flag lifecycle

After a feature flag has been flipped on for all environments be mindful to clean it up. That involves removing all mentions of that flag in the source code and deleting it from ConfigCat. You will need to contact an administrator to delete the flag.

Feature flag for applications

You can introduce feature flags to applications. The flag determines whether the applications is accessible for users. See readme on further details on how to implement.

here