传统意义上，软件发布被认为是工程和商业之间沟通的一种方式，
内部发布和对外发布的区别
。 工程把经过测试的代码交给商业，后者继而把它向市场发布，然后一个周期就完成了。然而，在敏捷中软件发布可以分成内部发布和对外发布两大类。这有助于在工 程和商业之间创建松散的耦合关系。工程创建内部发布，商业可以选择其中之一用于对外发布。在最近Cutter Consortium上的一篇文章中（下载代码是RELEASEMYTH），来自BMC公司的Israel就在软件世界中如何区分这“两”种发布的问题，引发了一场有趣的争论。他认为，内部发布和对外发布应该是同一个硬币的两面，
提供特定特性和功能的一套代码是一样东西，市场和销售使用这套代码以达到经营目标完全是另外一样东西。这两个活动不仅不同，也没有必要通过1比1的关系绑定在一起。他用一个有趣的例子来形象比喻， 一个水池有两个水管，一个是进水管，另外一个是出水管。他把工程比作进水管，商业比作出水管。
把这个例子中的进水管想像成工程，出水管想像成商业。工程可以按照自己的步调发布版本，商业可以从发布的版本中自由选择，管理资料
《内部发布和对外发布的区别》(https://www.unjs.com)。在此范例中，市场没必要某个版本完成后立刻对外发布，它可能3个月后再发布；也可能时间更晚，与另外一个版本同时发布；可能基于一定的根据，使用某个版本；或者也有可能让某个版本永远不发 布。Israel提到，由于现在工程和商业松散耦合，他们可以达到流畅发布的概念，让软件变得持续有活力。工程按照自己合适的步调发布内部版本，商业可以决定什么时候哪个版本作为外部发布，让客户使用。
对这篇文章评论时，Ryan提供了一些额外的启示，Israel的团队每对外发布1次，内部发布3次。他提出其好处是能得到有价值的反馈，商业继而可以使外部发布效果更好。Ryan认为，
这样好极了！结果是，我指导大多数敏捷团队时让他们这样开始，保证他们“内部发布”的频率是销售、运营、以及市场上习惯的频率的2倍。用这种方式你能有一个版本用于得到反馈，并把给市场的“对外发布”做的更好。Israel认为，采用敏捷方法，内部发布更多更快，使得软件更流畅、更有活力。这让传统的发布流程过时了。把发布区分开可以帮助工程和商业按照自己的发布模式工作，而不会互相打乱发布频率。
查看英文原文：Difference Between Internal and External Release
本文出自：http://www.infoq.com/cn/news/2009/01/internal-external-release