交付驱动开发（DDD）

5.00/5 (3投票s)

2018年8月22日

4分钟阅读

12165

通过交付驱动开发

引言

本文旨在介绍一种新的开发方法论，称为“交付驱动开发”（Delivery Driven Development）或 DDD。该方法论目前已在广泛的组织中取得巨大成功。

交付驱动开发（DDD）并不取代现有的方法论，例如测试驱动开发（TDD）或敏捷开发，而是对其有效性进行补充和增强。

该方法论的目的是提高交付的重要性，使其超越开发的附属地位。相反，在软件开发生命周期（SDLC）的初始分析和设计阶段之后，交付通道应成为首要考虑因素。

通过发布本文，我希望能与社区互动，并欢迎建设性的同行评审。

在 20 世纪 90 年代乃至 21 世纪初，交付通道的类型通常很有限。当时还没有Github、Azure 或 AWS，云托管的例子也很少。软件通常在本地托管，只有少数共享基础设施的例子。此外，随着公司越来越重视安全性，安全等障碍也日益增加。

尽管一家公司可能有许多客户，但与现在相比，交付通道的差异化和交付过程的复杂性要小得多。

过去，许多公司都采用了 TDD，并根据项目选择瀑布开发或敏捷开发方法论。这些实践通常以不同的成功程度得到应用。

无论是否准确的评估方法，用于确定这些实践成功与否的标尺通常是交付结果。

这在流程中造成了模糊性，因为交付通道不受 TDD、瀑布、敏捷或任何其他知名方法论的直接控制。

与大多数方法论一样，这种方法论并非适用于所有公司或项目。事实上，除非您要部署给许多客户，每个客户都有不同的部署通道和逻辑，否则这种方法论的好处可能并不显而易见。

例如，一家成功实施该方法论的软件供应商至少有 100 个客户。每个客户在每个环境中至少有 5 个环境，每个环境中有 3 个部署目标。有些客户在本地托管解决方案，有些则使用共享基础设施或云进行托管。此外，每个客户在硬件、策略和规则方面都有不同级别的安全性。

DDD 由五个步骤组成，用于驱动解决方案的分析、设计、实现、测试和交付。

通道分析是“何处”的步骤。它涉及识别部署资产的目的地。

“目的地”这个词是一个非常宽泛的术语，旨在包含所有可能的场景。对于许多公司来说，这一步将包括对以下方面的考虑：

通道设计是“如何”的步骤。它涉及确定部署资产的交付方式。

将大型复杂解决方案部署到一组目标服务器、服务和存储库的 MSI（Microsoft Installer）时代即将结束。

在大多数情况下，构建和发布过程在所有项目中将保持基本不变。但是，部署过程可能会因客户的基础设施、平台和安全模型而有所不同。对于许多公司来说，这一步将包括对以下方面的考虑：

通道实现是“执行”的步骤。它可能涉及一个或多个通道的配置。此步骤很大程度上取决于通道设计步骤和可用工具。

用于建立部署通道的常用工具包括 Team Foundation Server (TFS) 和 Octopus Deploy。对于许多公司来说，这一步将包括对以下方面的考虑：

通道测试是“修复”的步骤。它涉及部署通道的端到端冒烟测试。预计此步骤将识别可能影响成功发布的任何问题。对于许多公司来说，这一步将包括对以下方面的考虑：

通道交付是最后但至关重要的步骤。它涉及实际部署一个版本或候选版本（RC）。

此步骤还应包括在目标环境中对已发布版本进行全面冒烟测试，然后才能正式移交给客户进行用户验收测试（UAT）。