我们的应用程序使用MySQL数据库和更多服务。
要将我们的应用程序连接到这些服务器，我们将用户名和密码保存在prod.config文件中。如果我们在dev中，我们使用dev.config文件，依此类推......
最近，我一直在研究行业中的良好实践（例如https://12factor.net/），其中大多数（如果不是全部）都指定了用户名和pwd等信息来连接数据库和其他服务不应该是conifg文件而是ENV变量。
如果您不知道12因素规格是什么，可以查看这个免费教程：
现在，起初看起来很好。像Travis或CircleCI这样的许多CI工具已经迫使你这样做了。这里的问题是你最小的应用程序使用多个服务。
在我们的案例中，对于我们最小的应用程序，我们需要13个ENV变量。不属于任何特定文件的变量，它们都必须位于它们运行的机器的ENV中。
我没有看到如何将其视为一种良好做法。我理解不用所有这些敏感数据推送你的confg文件的主要想法，但这种方法带来了几个问题：
答案 0 :(得分：0)
我要回过头来向你提出一个问题：你为什么要尝试从测试环境连接到生产数据库？
CI工具的优点在于它们允许您启动Docker容器以充当测试服务。在您的生产代码中，最好将密码保存在环境变量中，这主要有两个原因： 1.）如果某人掌握了您的代码，他们就可以访问您的数据库。它需要额外的安全级别，这是不切实际的。 2.）如果某人 获取了您的密码，您希望能够快速更改它们。如果您的代码引用环境变量而不是硬编码字符串，则更容易做到这一点。
当您转移到CI系统时，第2点变得没有实际意义，但第1点变得非常重要。使用Travis和CircleCI，您的配置文件是公共的。如果您将生产密码放入配置文件中，我（或更恶意的人）可能会扫描您的文件并跳转到您的数据库。我听说过黑客为配置文件中的硬编码密码抓取公共存储库的故事。使用像CircleCI这样的工具会更容易。
您在Travis和CircleCI中设置的环境变量应存储在存储库级别 - 您不需要移动变量或保存它们。
生产系统中的环境变量应设置为启动脚本的一部分。这在很大程度上取决于您使用的是哪种服务，所以我不会在这里详细介绍。