Deployment 使开发、测试、登台和产品环境彼此不同的好策略

我终于开始使用IDE（IntelliJ），并惊讶于它为我上一个项目节省了多少时间。在我的下一个项目中，我想跟上使用好的工具来节省时间的趋势

我正在为一个新项目设置我的开发环境，我想设置我的开发环境，这样我就可以花更多的时间编码，更少的时间部署和手动测试。我想使用Git、Vagrant等工具，以及所有从长远来看可以节省时间的开发工具，只要你投资学习它们

我希望能够有一个在我的笔记本电脑上运行的开发环境，一个在网络上运行的登台环境（一些集成，如Facebook，如果没有一个实时站点，很难进行测试；我还希望登台环境的设置与生产环境几乎完全相同），以及一个发布的生产环境

与生产环境相比，开发环境和登台环境有一些小的变化：例如，不希望登台环境能够意外地向实际客户发送电子邮件

我认为需要在代码中的某些地方使用不同的域名，这取决于代码运行的环境，或者可能使用模拟API而不是实际API，或者电子邮件都被转储到测试域名，等等

看起来最安全的方法是让代码假设它在开发模式下运行，除非它被告知它在暂存或生产中

有哪些好的技术可以告诉代码它在什么环境中运行？环境变量？库中包含的常量

人们使用什么构建工具来处理HTML之类的事情呢？在HTML中，“编译”可能是用于生产或暂存域名，也可能是缩小规模

我喜欢在开发过程中编辑我的代码并重新加载浏览器——也许这是我应该停止使用的一个拐杖，但我希望有一个工作流程可以让我轻松地做到这一点

还想让它很难搞砸。我不想意外地将开发模式中的代码部署到生产环境中。我从来没有使用过CI工具，这是人们使用CI工具的原因吗，也就是说，这是他们帮助的吗？当你还没有一个庞大的团队时，它们值得使用吗

特别感谢与IntelliJ配合良好的建议。

最好的策略是不要告诉代码它在什么环境下运行。让环境告诉代码需要在该环境中运行什么

您的代码永远不应该特别检查它是在开发中还是在暂存中，或者其他什么。（如果确实如此，则无论何时添加、删除或重命名环境，都需要更改代码）。相反，当您的代码需要执行依赖于环境的操作时，它应该查看特定于该操作的配置。如果在开发、暂存和生产中需要不同的资产服务器，请为资产服务器定义一个配置变量，并在不同的环境中以不同的方式设置该变量。如果您有一些只应在某些环境中运行的功能，如发送邮件，请定义一个配置变量，说明是否使用该功能

在环境中定义配置的常用方法是环境变量或配置文件。在您使用的web框架中，可能有一些标准的方法来定义配置；如果是的话，就用这个

您的代码，无论是Java还是HTML，在所有环境中都应该是相同的。您希望编写和编译Java一次，并在所有环境中使用编译后的类，而无需重建。环境之间的所有差异都应该在配置上有所不同，而不是在代码上有所不同。（没有库常量。）因此，将错误的代码部署到错误的环境没有问题；代码总是一样的

您确实需要在正确的环境中进行正确的配置。如何做到这一点取决于您如何进行配置（同样，请检查您的框架文档），但通常通过设置环境变量或将配置文件复制到适当的位置或任何一次，并在部署过程中完全不接触它们，为环境设置一次配置

不破坏部署的方法是完全自动化，因此您只需“按一个按钮”（实际上是运行一个脚本）即可进行部署，并且没有任何手动细节会出错

---

持续集成虽然很重要，甚至对一个人都很有用（你想每次都手动运行你的构建吗？），但这与你的大部分问题没有多大关系。IntelliJ虽然很棒，但在这里也不太相关。您的部署当然应该只依赖于命令行工具。当前的最佳实践是为您的应用程序提供一个完全自动化的测试套件，在CI中自动运行它，如果测试通过，则自动部署它（“连续部署”），但这肯定是另一个主题。

正如Dave正确建议的那样，特定于环境的配置文件是针对每个环境可以更改的所有配置的方法，包括：第三方API连接、数据库连接、电子邮件处理、路径、日志设置等。只要配置文件设置正确，软件应该能够在任何平台上运行。请注意，这是特定于环境的配置。。。应用程序本身的配置设置可以位于其他位置（数据库、其他文件等）

更一般地说，这个问题详述了我们构建的一些原因。与其说它是一个持续集成工具，不如说它是一个持续交付工具（尽管它设计用于同时执行这两个功能，或者与Jenkins等现有工具集成），但它有助于完成您在问题中列出的所有事情，尤其是有关配置文件管理和意外部署预防的部分。它可以迫使你跟随