交付驱动开发（Delivery Driven Development，简称DDD）是一种新兴的软件开发方法论，它在许多组织中取得了巨大成功。DDD并不是要取代现有的方法论，如测试驱动开发（Test Driven Development，简称TDD）或敏捷开发（Agile），而是补充和增强它们的有效性。
DDD的核心目的是提升交付的重要性，使其不仅仅是开发过程中的一个后续考虑。相反，交付渠道成为在SDLC（软件开发生命周期）的分析和设计阶段之后首先要考虑的问题。
通过发布这篇文章，希望与社区进行互动，并邀请同行进行建设性的评审。
在90年代甚至21世纪初，交付渠道的类型通常是有限的。那时没有GitHub、Azure或AWS，云托管的例子也很少。软件通常在本地部署，有一些共享基础设施的例子。此外，随着公司对安全性的意识增强，安全障碍也有所增加。
尽管公司可能有很多客户，但交付渠道的差异性和交付过程的复杂性比现在要小得多。
过去，许多公司采用了TDD，并根据项目的不同，采用了瀑布式或敏捷开发方法论。这些实践通常以不同程度的成功被采用。
无论是否准确，用来衡量这些实践成功或失败的常用标准是交付结果。
这在过程中造成了模糊性，因为交付渠道并不直接受TDD、瀑布式、敏捷或其他知名方法论的控制。
与大多数方法论一样，这种方法论并不适合每个公司或项目。实际上，除非要部署给许多客户，每个客户都有不同的部署渠道和逻辑，这种方法论的好处可能不会立即显现。
例如，一个成功实施这种方法论的软件供应商至少有100个客户。每个客户至少有5个环境和每个环境中的3个部署目标。一些客户在本地部署解决方案，其他客户使用共享基础设施或云托管。此外，每个客户在硬件、政策和规则方面都有不同程度的安全性。
DDD由五个步骤组成，以推动解决方案的分析、设计、实施、测试和交付。
渠道分析是“在哪里”的步骤。它涉及确定部署资产的目的地。
“目的地”这个词是一个非常广泛的概念，旨在包容。对于许多公司来说，这一步将包括考虑：
Nuget MyGet npm Windows FileSystem Windows Web App Windows Service Azure SQL Azure Web App Azure App Service SqlServer Octopus Deploy（部署包的目的地）
渠道设计是“如何”的步骤。它涉及确定如何交付部署资产。
对于大型、复杂的解决方案，使用MSI部署到一组目标服务器、服务和存储库的日子即将结束。
在大多数情况下，构建和发布过程在所有项目中基本相同。然而，部署过程可能会根据客户的基础设施、平台和安全模型而有所不同。对于许多公司来说，这一步将包括考虑：
目标环境，即开发、用户验收测试（UAT）、培训、暂存、生产目标机器目标机器角色，例如Windows服务器、应用服务器、数据库服务器负载均衡器灾难恢复（DR）计划Windows、SQLServer和SharePoint的版本基于Windows或令牌的认证防火墙规则和Windows组策略在Octopus Deploy的情况下，要使用的Tentacle类型。这可能会根据环境而有所不同。
渠道实施是“做”的步骤。它可能涉及配置一个或多个渠道。这一步主要由渠道设计步骤和可用工具驱动。
用于建立部署渠道的常用工具包括Team Foundation Server（TFS）和Octopus Deploy。对于许多公司来说，这一步将包括考虑：
与客户紧密合作，确保目标机器可以与部署服务器通信，例如Octopus Deploy和Chocolatey设置存储库，例如MyGet和npm通过中央配置管理门户配置环境，例如Octopus Deploy
渠道测试是“修复”的步骤。它涉及部署渠道的端到端冒烟测试。预计这一步将识别出可能危及成功发布的问题。对于许多公司来说，这一步将包括考虑：
服务帐户，例如Octopus Tentacle服务帐户、Web服务帐户和Windows服务帐户环境配置访问和从Chocolatey下载的权限更新注册表的权限创建和配置IIS Web应用程序的权限安装Windows服务的权限配置MSDTC的权限创建SQL Server数据库的权限运行未签名的PowerShell脚本的权限安装和激活SharePoint解决方案以供SharePoint站点使用
渠道交付是最后但至关重要的步骤。它涉及实际部署一个发布或发布候选版本（RC）。