我终于开始使用IDE（IntelliJ）并且惊讶于它在我上一个项目中节省了多少时间。在我的下一个项目中，我希望保持使用可以节省时间的好工具的趋势。
我为一个新项目设置了我的开发环境，我想设置我的开发环境，这样我就可以花更多的时间编写代码，减少部署和手动测试的时间。我希望使用像 Git ， Vagrant 这样的工具，以及一旦你投入学习它们就可以节省时间的所有开发工作。
我希望能够拥有一个在我的笔记本电脑上运行的开发环境，一个在网络上的暂存环境（没有现场网站，某些集成如Facebook很难测试;我还希望暂存环境是设置与生产几乎完全相同），以及发布的生产环境。
与生产相比，适用于开发和登台环境的细微更改：例如，不希望登台环境能够意外地向实际客户发送电子邮件。
我发现在代码中需要使用不同域名的某些位置，具体取决于运行代码的环境，或者可能使用模拟API而不是实际的API，也许电子邮件都被转储到测试域名等
似乎最安全的方法是让代码假设它在开发模式下运行，除非它被告知它正在升级或生产。
有什么好的技术可以告诉代码它运行的环境是什么？环境变量？常量包含在库中？
人们使用什么 build 工具来处理HTML之类的东西，其中＆＃34;编译＆＃34;可能正在投入生产或暂存域名，也许正在缩小？
我喜欢编辑我的代码并在我开发时重新加载我的浏览器 - 也许这是一个我不应该习惯的拐杖，但我喜欢一个工作流程，可以很容易地做到这一点。
也想让人难以搞砸。我不想在开发模式下意外地将代码部署到生产环境中。我从未使用CI工具，这是人们使用CI工具的原因，即他们帮助的是什么？当你没有庞大的团队时，它们是否值得使用？
与IntelliJ配合得很好的建议特别受到赞赏。
答案 0 :(得分：5)
最佳策略 not 告诉代码它正在运行的环境。让环境告诉代码在该环境中需要运行什么。
您的代码永远不应该专门检查它是处于开发阶段还是正在进行中。 （如果确实如此，则无论何时添加，删除或重命名环境，都需要更改代码）。相反，只要您的代码需要执行依赖于环境的操作，它就应该查看特定于该内容的配置。如果您需要在开发和登台以及生产中使用其他资产服务器，请为资产服务器定义配置变量，并在不同环境中以不同方式设置该变量。如果您有一些应该只在某些环境中运行的功能，比如发送邮件，请定义一个配置变量，说明是否使用该功能。
在环境中定义配置的常用方法是环境变量或配置文件。可能有一些标准的方法来定义您正在使用的Web框架中的配置;如果是这样，请使用它。
您的代码，无论是Java还是HTML等，都应该在所有环境中都相同。您希望编写和编译Java一次，并在所有环境中使用已编译的类而无需重建。环境之间不同的一切应该在配置上有所不同，而不是代码。 （没有库常量。）因此，将错误的代码部署到错误的环境中没有问题;代码总是一样的。
您需要在正确的环境中获得正确的配置。如何做到这一点取决于你如何配置（再次，检查你的框架文档），但通常通过设置环境变量或将配置文件复制到位或任何一次而不是触摸它们来为环境设置一次配置所有在部署期间。
不搞砸部署的方法是完全自动化，因此您只需要“按下按钮”（实际上，运行脚本）进行部署，并且没有手动细节可以出错。
持续集成虽然必不可少，但对于一个人来说也很有用（您是否希望每次都手动运行构建？）与您的大部分问题没有多大关系。 IntelliJ虽然很棒，但在这里也不太相关。您的部署当然应该仅依赖于命令行工具。当前的最佳实践是为您的应用程序提供一个完整的自动化测试套件，在CI中自动运行并自动部署（“持续部署”），如果测试通过，但这肯定会进入另一个主题。
答案 1 :(得分：1)
正如Dave正确建议的那样，特定于环境的配置文件是可以改变每个环境的所有配置的方法，包括：第三方API连接，数据库连接，电子邮件处理，路径，日志记录设置等。我们的想法是，只要配置文件设置正确，软件就能在任何平台上运行。请注意，这是特定于环境的配置... 应用程序本身的配置设置可以存在于其他地方（数据库，其他文件等）
更一般地说，这个问题详细说明了我们构建BuildMaster的一些原因。它更像是持续交付而不是持续集成工具（虽然它旨在同时执行，或与Jenkins等现有工具集成），但它有助于完成您在问题中列出的所有事项，尤其是有关配置文件管理和意外部署预防的部分内容。它可以强制您遵循特定的环境序列，以确保在最终生产之前对每个代码进行测试，并通过向部署计划添加简单操作来自动处理每个环境的配置文件部署。
虽然它没有直接与IntelliJ集成，但您应该使用某种形式的源代码控制 - 并且CI方面可以在您办理登机手续或手动时提取更改＆＃34;创建构建＆＃34 34。
如果您有兴趣，我会开始here并且应该很容易弄清楚如何扩展流程以遵循您的想法。虽然这个例子是基于.NET的，但用基于Java的行为替换这些行为是微不足道的。