Gitlab Feature Flag是否支持审批功能？能否实现变更需指定组审核？

GitLab原生确实没有内置Feature Flag（FF）修改的审批流程，但可以通过以下几种方式实现类似需求：

方案一：依托代码仓库的MR审批流程（最简便） #

将Feature Flag的配置文件（比如.gitlab/feature_flags.yml）纳入代码版本控制，把FF的状态变更转化为代码变更：

• 把所有FF的定义和状态都写在这个配置文件里，提交到仓库主分支
• 开启主分支保护，设置只有指定用户组的成员才能合并MR，并且要求该组至少1人审批才能合并
• 普通用户需要修改FF状态时，必须提交MR修改配置文件，等待指定组审批通过后，合并到主分支才会生效
• 配合GitLab的CI/CD，合并后自动触发FF的同步（如果需要）

这种方式完全利用GitLab原生功能，不需要额外开发，还能保留所有FF修改的历史记录。

方案二：自定义API拦截+审批脚本 #

利用GitLab的Feature Flags API，自己编写简单的审批逻辑：

• 禁止普通用户直接在GitLab界面修改FF，只允许通过API操作
• 编写一个中间脚本/服务，接收FF修改请求，先检查请求者是否属于指定审批组
• 如果不属于，触发审批流程（比如创建一个GitLab Issue，@指定组人员），只有当审批人在Issue里标记"批准"后，脚本才调用GitLab API执行FF状态修改
• 可以把这个脚本集成到内部的运维工具或者CI/CD流水线中

方案三：Webhook结合外部审批系统 #

通过GitLab的Webhook监听FF相关事件，配合自定义审批服务实现：

• 配置GitLab的Webhook，监听feature_flag_updated事件
• 当有用户尝试修改FF时，Webhook把事件数据发送到你的自定义审批服务
• 服务验证操作人权限：如果是指定组成员，直接允许；否则触发审批流程，待批准后再调用API完成修改（或者直接拒绝未授权的修改）

注意事项 #

• 方案一的局限性是FF状态变更必须走代码MR，适合对变更流程要求严格的场景；如果需要更灵活的即时修改，方案二或三更合适
• 所有方案都需要提前配置好GitLab的用户组权限，确保指定审批组的成员有足够的权限操作FF或合并MR

内容的提问来源于stack exchange，提问作者Librorio Tribio