功能分支部署与分支保护部署答案

【问题标题】：Feature Branch Deployment vs Branch-Protected Deployment功能分支部署与分支保护部署
【发布时间】：2022-08-24 15:57:11
【问题描述】：

部署时如何兼顾安全性和灵活性？

拥有部署到任何功能分支的能力对 QA 来说是件好事，因为他们甚至可以在代码审查之前测试应用程序。
- 某些场景：由于地域限制，开发人员无法访问某个功能，只有团队内部的 QA 可以访问它。
- 修复极端情况场景的周转时间更快。
- 不安全，因为任何有权访问存储库的人都可以提交访问秘密信息（密钥库、分发证书、API 密钥等）的提交
分支保护部署是安全的，但不够灵活。
- 通常情况下，在部署提交之前会有代码审查员，所以它有点安全。
- 如果代码审查需要很长时间（在我们的案例中总是如此），则多个团队的工作效率可能会降低。
对部署环境的访问受限的功能分支部署。
- 但是怎么做呢？
- 我发现的一些想法是使用pre_build_script，您可以在跑步者执行之前添加一些条件。例如，存储.gitlab-ci.yml 的校验和以防止进一步编辑，除非它已经过审查。但这并不妨碍其他文件访问环境变量，例如，在 Android 中，有 build.gradle 可以访问任何环境变量。
最好有#3 解决方案，但我们不确定如何安全地实现这一点。

如果有帮助，我的问题是针对移动部署（iOS 和 Android）的。

标签： git gitlab continuous-integration continuous-deployment cicd

【解决方案1】：

在部署方面，第一点似乎是同时具有安全性和灵活性的最可行的选择。这里唯一非常严重的问题是安全性，因为任何人都可以访问秘密信息。

好吧，很遗憾人们仍然以这种方式将他们的秘密存储在访问控制是一个挑战的存储库中。理想情况下，秘密需要dynamically injected 进入管道并存储在保险库中。如果你能做到这一点，第一个选项是最好的出路。有很多关于如何管理动态机密的文章，例如：https://ozone.one/blog/basics-of-dynamic-kubernetes-secrets-management-ozone/

祝你好运！

【讨论】：