其实完全可以使用Maven做持续交付，比如说，为每个版本创建一个release build。当然，这个会和Maven的“release build只以生产部署为目的，不会经常创建”的理念矛盾。而且，像Nexus和Artefactory这样的私服都有删除旧的snapshot版本的清理功能，但不允许删除release版本。所以一个活跃的持续交付团队，可以产生几十个版本，这样很容易吃掉服务器上几G到几T的空间。

　　矛盾点：更着重测试可部署性

　　标准的持续交付的实践方式是，通过基本的持续集成自动地把每个版本部署到与真实生产环境尽量贴近的模拟环境中，使用相同的发布流程和工具。这对验证每次提交的代码是否是“可以发布”是至关重要的，但是这样对持续集成的要求比现在大部分开发团队正在使用的要高很多。

　　举个例子，在没有要求持续发布的持续集成，可能会使用Ant或者Maven将应用发布到嵌入应用服务器然后进行自动的功能测试。开发者使用和维护都很方便，但是这很可能不是生产环境中应用发布的方式。

　　所以持续交付团队会自动化发布到一个更贴近真实生产的环境，包括不同的网页/app/数据层，并且使用在真正生产中使用的部署工具。当然，这种更像生产的部署阶段更加可能出错，因为它增加了复杂性，而且可能对开发者而言更难以维护和修正，因为这些工具更像是给系统管理员而不是给开发者使用的。

　　不过这是个机会，可以和管理运营团队一起创建一个更可靠、更易于支持的部署流程。但是实现和稳定这程的难度会比较大，可能会影响开发的进度。

　　值得采用持续交付吗？

　　考虑到有这么多冲突的地方，那持续交付有什么好处，值得我们从传统敏捷迁移过来呢？特别是对于那些实际上不太可能在一次迭代中有好几次发布到生产环境的团队来说，更是要问这个问题。值得这么做的原因如下：

　　尽早发现部署可能遇到的问题以降低风险

　　增加灵活性，组织可以选择在任何时候发布，并把附加的代价和风险控制到小

　　把生产发布涉及的每个人拉进来（比如QA、运营等），使得整个流程更有效率。组织必须识别出流程中的困难区域，并且通过自动化、更好的协作或者改进工作方法等方式找到克服它们的方法。

　　通过持续的演练发布流程，组织会对这个过程很精通，然后发布会变得自动化，像阵痛过后自由的呼吸，像生孩子一样。

　　提升软件质量，因为团队不能再像以前一样把问题留到后面，他们必须现在解决。

　　消除冲突

　　当引入持续交付的时候，我以上所说的冲突点会频繁出现。我希望当这些问题出现的时候，了解冲突的根本原因，可以有助于更好地讨论并解决它们。如果开发者一开始不愿意打破他们习惯的“正确”做事方式，或者认为持续交付所带来的串行工作太复杂，或者很难理解这些实践的目的和价值，那么我希望他们可以尽量开放地给自己一个机会去尝试一下。一旦这些实践方式根植于一个组织并且变得成熟，团队成员们往往会觉得很难退回到以前的做事方式。

　　编者按：我重新定义了“传统敏捷”中让软件可以发布的方式。这个定义不是适用于所有敏捷实践，但是我看到的，大部分主流概念都认为敏捷需要停下工作来将软件变得可发布。