让我们谈谈持续集成。是的，我的意思是“持续集成”，而不是“持续交付”。

在小型迭代代码检查中的敏捷技术，以及应对大的代码群所进行的测试，这些之中的持续集成是一项长期的开发实践。但是随着软件专业人士开始关注持续交付，持续集成就渐渐被漠视了。

与其一直在寻找最佳的实践，软件专业人士还不如继续看好持续集成。他们已经这样做很久了，他们不会质疑这么做是否正确。最近的一次对话中，Coveros的CEO以及软件开发咨询顾问Jeffery Payne告诉我说，这个方法是错误的。

持续集成：并不是在构建那么简单

Payne说，当软件专业人士讨论持续集成时，大部都是关于自动化构建流程。“构建是他们对完成的定义。”但是构建只是战役的一半。成功的构建告诉你，从字面上说，就是把代码团结在一起，他解释说。“这并不代表这就中代码的工作方式。”持续集成实践还应该包含自动部署代码到他们所在的平台，Payne说。“你一定要确保它的配置是正确的，且所有集成问题已经得到解决。”

确保持续集成还包括自动部署，而不是广泛概括了持续交付的策略，这是一个实用的方法，因为这样做是对的，种什么因，得什么果，Payne说。“当你开始持续集成时，你就给持续交付设立了一个舞台。不你的持续集成实践是良好的，强壮的时，持续交付就是下一个逻辑步骤了。”

在我们对话中，Payne还谈了他对持续集成、持续交付、自动测试作为大型 DevOps环境的一部分的看法。这一对话中，他分享他的一些观点，“为什么DevOps改变了一切，”这是他将要在2015年6月的Agile Development Conference West上分分享的。

一切都是为了代码

当持续集成把部署环境考虑进去时，实际来说，软件团队要创建一个环境，即Payne说到的“一切都是为了代码。”换句话说，支持代码的基础设施要部署，而不只是应用程序本身，以表示为代码。

DevOps方法可提早对问题进行检测，而这在之前只能在开发后期才可以。“你能够知道代码是如何集成到它的平台中的，” Payne说。另外，DevOps 让QA和测试更高效。“如果你在云端设置了一个虚拟化测试环境，测试人员不必再依靠运营人员来设置测试环境，”他说。“你可以控制一切”关于配置的事情。这是与传统方法最大的不同，即只有源码可控，Payne说。“你不得不返回，查出发生了什么事情。”

这样，让我们了解你的想法。你的持续集成实践包括DevOps吗？还是，你只局限在自动构建领域？你是否在做持续交付？如果是，你的集成流程工作如何？