构建自动化与部署自动化与持续集成

我想变得更高效，我想高效地使用操作工具。

考虑到这一点，我想了解有关持续集成的更多信息，但是似乎有很多不同的事情要涉及到。

我实际上在工作中使用Jetbrains套装（IntelliJ，WebStorm ...），所以我想继续使用它们，并且我想使用TeamCity，它似乎是一个不错的工具，带有许多用于持续集成的插件。

我的问题是我不知道它们之间有什么区别：

• 楼宇自动化（TeamCity是这种软件）：我知道我们可以使用远程VCS存储库来构建应用程序，这很棒，但是这样做的主要目的是什么？在执行此操作时，什么样的信息很重要？实际上，我已经知道我的软件是否在本地构建，而我的团队也是如此。那么，在不部署自动化的情况下使用它的目的是什么？

• 部署自动化（TeamCity似乎并不容易做到）

• 持续集成（似乎是上述两者的结合）
• 持续交付（这到底是什么？为什么它与持续集成不同？）

您能帮我多了解一点吗？

维基百科对这些术语中的大多数都给出了很好的总结。这是我对它们的看法：

• 生成自动化是自动构建软件，而不是手动调用编译器。这可以通过诸如Make或Ant之类的工具来完成。

• 部署自动化是采用您构建的软件并将其部署或安装在测试或生产系统上。

• 持续集成意味着在开发人员检入代码并运行单元测试以确保代码仍能正常工作时，具有自动化流程来持续构建软件。例如，服务器可能每隔15至30分钟醒来一次，扫描VCS以查找新的签入，然后进行更新并构建项目（如果进行了任何更改）。除了执行编译步骤外，这也是运行自动化单元测试和代码质量检查的绝佳机会。

• 持续交付是所有先前概念的结合，在该概念中，还将软件构建也部署到测试系统，并且可以选择执行测试和生成报告。

至少，您需要具有构建自动化，即某种构建脚本。这使您可以单击一个按钮或发出一个命令来构建项目。这样做的好处是减少了手动运行步骤中的错误。复杂的构建环境可能涉及生成代码（从配置中考虑DAO，接口代码（例如JAXB），编译代码，将其打包，自定义元数据等）。有很多工作要做，您需要一个清单：为什么不将清单做成您的构建脚本，并使用工具来运行它？它减少错误并提供一致性。

接下来是CI：这确实很不错，但并非严格要求。它有助于尽早发现构建问题。如果您有多位开发人员在一整天中检入代码，并且可能没有持续同步他们自己的工作区，则存在他们的更改相互干扰的风险。我指的是静态代码错误，而不是版本控制冲突。CI构建服务器将减轻这种风险。

最后，我们有部署步骤。这里的想法是为了节省时间并减少手动部署软件带来的错误。与构建自动化非常相似，有一百种方法可以破坏软件部署。我个人在办公室待到很晚，以解决许多手动部署问题，这在我们需要为明天到现场的客户提供功能正常的系统时。自动化多个系统会带来更大的风险：现在，我们有多个系统，而不是一个系统可能崩溃或出现奇怪的错误，系统可能会出错。但是，与那些错过检查清单上的步骤或发出错误的命令并弄乱部署的人相比，这种风险要低得多。如果幸运的话，您可以简单地还原数据库备份并重新开始，如果不幸的话，错误可能会导致系统无法正常运行。它是软件缺陷吗？技术人员是否未正确设置配置？如果您使过程自动化，那么这将需要花费时间进行诊断，可能没有的时间以及不需要花费的时间。

• 持续集成是一种每天将所有开发人员更改合并到一个共享主线中的实践。现在，这种做法无处不在，以至于看起来似乎并不重要，但是传统上，团队会孤立地工作数周甚至数月。当单独的工作流合并在一起时，结果就是“整合地狱”。连续集成通常与共享主线的自动构建一起使用，以尽早发现问题，但它更多的是关于频繁提交和开发人员的工作流程，而不是DevOps。

• 自动化的构建对于发现可能导致构建在本地通过但在构建服务器上失败的问题非常有用（例如，您忘记签入文件，构建服务器上的依赖项不匹配）。让构建服务器检测到这些问题意味着您可以在团队成员之前解决它们。

• 持续交付涉及持续部署，运行和测试软件。尽管自动构建可以确保您的软件已经真正构建（并且单元测试通过了），但这并不意味着您的部署脚本仍然可以运行，也不意味着您的软件实际上是端到端运行的。连续交付的目标是进行一系列检查，以确保主线保持在适合于部署到生产的状态。

• 连续部署是下一个逻辑步骤-自动部署成功通过连续交付管道的每个提交。这种做法有很多好处，但是对我来说，这里的主要思想是小的，频繁的提交风险较小。

我建议阅读本书以获取更多信息：

• 持续交付：通过构建，测试和部署自动化来发布可靠的软件

像许多构建工具一样，Teamcity只是一个中央应用，可让您运行许多不同的任务。这包括执行CI生成，完整发行版之类的生成，它允许您执行部署。如果要使用teamcity调用ant或nant在解决方案文件上运行msbuild，则还可以调用将执行部署的nant脚本。它可能需要一些脚本，但并不难。

我们将teamcity和bamboo用于完整的配置项，数据库配置项，并部署到INTegration环境。然后，我们使用teamcity进行完整版本构建并自动创建数据库迁移脚本。这些通过调出nant脚本的teamcity作业签入SVN。您猜对了，对于部署，我们使用teamcity召集南特来执行部署任务。这很有效，因为teamcity代理与teamcity服务器进行通信，并且该代理可以存在于DMZ位置中的一台服务器上，这有助于将代码移出防火墙等。因此，仅需teamcity或Bamboo即可处理整个情况。