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

Question

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

考虑到这一点，我想了解更多关于持续集成的知识，但是它似乎有很多不同的东西。

我实际上是在我的工作中使用Jetbrains套装(IntelliJ，WebStorm.)，所以我想继续使用它们，我想使用TeamCity，这似乎是一个很好的工具，有很多插件可以持续集成。

我的问题是我不知道以下几个方面有什么区别：

• 构建自动化(TeamCity是这类软件)：我知道我们可以使用远程VCS存储库构建应用程序，它很棒，但它的主要目标是什么？做这件事时，什么样的信息是重要的？事实上，我已经知道我的软件是否在本地构建，我的队友也是如此。那么，在不部署自动化的情况下使用它的目的是什么？
• 部署自动化(TeamCity似乎不容易做到)
• 持续集成(这似乎是以上两者的结合)
• 连续送货(这到底是什么？为什么它与持续集成不同？)

你能帮我理解一下这个吗？

Answer 1

维基百科很好地总结了大部分这些术语。以下是我对它们的看法：

• 建筑自动化正在自动化软件的构建方式，而不是手动调用编译器。这将通过诸如制作或蚂蚁之类的工具来实现。
• 部署自动化是将您构建的软件部署或安装在测试或生产系统上。
• 连续积分意味着在开发人员签入代码并运行单元测试以确保代码仍然工作时，让自动化流程持续构建您的软件。例如，每隔15到30分钟，服务器可能会醒来，扫描风险投资以获得新的签入，然后更新并构建项目(如果有任何更改)。除了执行编译步骤之外，这也是一个运行自动化单元测试和代码质量检查的好机会。
• 连续交付是以前所有概念的组合，其中软件构建也部署到测试系统中，可以选择地执行测试并生成报告。

至少，您需要具有构建自动化，即某种类型的构建脚本。这使您可以单击一个按钮或发出一个命令来构建项目。这样做的好处是减少了手动运行步骤所产生的错误。复杂的构建环境可能包括生成代码(从信任信息生成道斯、编写接口代码(如JAXB)、编译代码、打包代码、自定义元数据等等。有很多东西需要检查:为什么不将清单作为构建脚本，并使用工具运行它呢？它减少了错误并提供了一致性。

接下来是CI:这确实是很好的，但不是严格要求。它有助于尽早发现构建问题。如果您有多个开发人员一整天都在签入代码，并且可能没有经常同步他们自己的工作区，那么他们的更改就有可能相互干扰。我指的是静态代码错误，而不是版本控制冲突。CI构建服务器将降低此风险。

最后，我们有了部署步骤。这里的想法是节省时间，减少手工部署软件的错误。就像构建自动化一样，有上百种方法来破坏软件部署。我个人在办公室呆到很晚，在很多情况下，我们需要为明天到达现场的客户提供一个正常运行的系统，以解决手动部署问题。自动化多个系统会带来更大的风险:而不是一个系统可能崩溃或出现奇怪的错误，我们现在有多个系统可能出错。然而，这种风险远远低于某个人在检查表上遗漏了一步，或者发出了错误的命令并扰乱了部署。如果幸运的话，您可以简单地还原一个DB备份并重新启动，如果您运气不好，一个错误可能会导致系统不正确地工作。这是一个软件缺陷吗？技术人员没有正确设置配置吗？这需要时间来诊断，你可能没有的时间，和时间，不需要花费，如果你自动化的过程。

Answer 2

• 连续积分是一天几次将所有开发人员的更改合并到一个共享主线中的实践。这种做法现在如此普遍，似乎没有什么重要意义，但传统上，团队会在几个星期甚至几个月的时间里孤立地处理软件。其结果是“集成地狱”，当不同的工作流程合并在一起时。持续集成通常与共享主线的自动构建一起使用，以便早期发现问题，但它更多地是关于频繁提交和开发人员工作流，而不是关于DevOps。
• 自动构建对于发现可能导致构建在本地传递但在构建服务器上失败的问题是有价值的(例如，您忘记签入一个文件，构建服务器上的依赖项不匹配)。让构建服务器检测这些问题意味着您可以在队友之前修复它们。
• 持续交付包括持续部署、运行和测试您的软件。虽然自动化构建确保您的软件实际构建(并且单元测试通过)，但这并不意味着您的部署脚本仍然有效，或者您的软件实际上是端到端运行的。连续交付的目标是进行一系列检查，以确保主线处于适合部署到生产的状态。
• 连续部署是下一个逻辑步骤--自动部署成功通过连续传递管道的每个提交。这种做法有几个好处，但对我来说，这里的主要想法是，小而频繁的提交风险较小。

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

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

Answer 3

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

我们使用团队和竹的完整CI，数据库CI和部署到INTegration环境。然后，我们使用teamcity进行完整的发布构建，并自动创建db迁移脚本。它们通过调用nant脚本的teamcity作业签入SVN。对于部署，您已经猜到了，我们使用teamcity来调用nant来执行部署任务。这可以很好地工作，因为teamcity代理与teamcity服务器对话，并且代理可以存在于DMZ位置中的一个服务器上，这有助于将代码移到防火墙之外等等。所以，要处理整个场景，只需工作组或竹。