Bob Chesley

Bob Chesley's Blog

Approaches to using feature flags in GitLab

Bob Chesley,•softwaregitlabfeature flags
Back

GitLab Feature Flags - use a single repo or embed in individual projects?

Using a separate project just for feature flags in GitLab can be a good approach, especially if you have multiple services and frontend applications that need to share flags. This approach offers several benefits:

  1. Isolation: Keeping feature flags in a separate project isolates their configuration from the codebase of your individual services and frontend applications. This can help prevent accidental changes to flags when making code changes.

  2. Centralization: A dedicated project for feature flags allows you to centralize flag management. This can make it easier to control and monitor flags across different services and applications.

  3. Collaboration: If multiple teams or developers are working on different services or applications, a separate project for flags can provide a common space for collaboration on flag configuration without interfering with code development.

  4. Granular Access Control: GitLab provides access control at the project level. By having a separate project for flags, you can control who has access to modify and manage flags independently of codebase access.

  5. Versioning and History: With a separate project, you can maintain a clear version history of your feature flag changes, making it easier to track changes over time.

  6. Testing and Release: When you have a dedicated project for flags, you can test and release flag changes independently of code changes. This can be particularly useful for managing gradual rollouts or A/B tests.

  7. Performance: Separating flags from code can potentially have performance benefits, as flag evaluation and management might be optimized in a dedicated project.

However, there are some considerations to keep in mind:

  1. Complexity: Managing multiple projects can introduce some complexity, especially if you're already working with multiple services and applications.

  2. Communication: Having a separate project might require clear communication between teams to ensure that everyone is aware of flag changes and their implications.

  3. Overhead: Maintaining an additional project involves some overhead in terms of setup, configuration, and ongoing management.

Ultimately, whether to use a separate project for feature flags depends on the specific needs and structure of your development workflow, as well as the level of isolation and control you want for your feature flag management. It's important to weigh the benefits against the potential complexities and overhead, and choose an approach that aligns with your team's goals and processes.

The pros and cons mentioned here would likely apply to any software management platform, not just GitLab.