BuildDirect 是一家总部位于温哥华的在线建材零售商，通过网站向房主和承包商销售地板、瓷砖等建筑材料。
对一家门店就是软件的零售商来说，功能上线的速度是一个商业问题。定价调整、供应商集成和结账流程改进，只有在客户用得上的那一刻才有价值。正是这种依赖关系让 BuildDirect 找到了 SEYA。
项目
BuildDirect 的交付流水线包含其发布流程所需的晋级和审批环节。SEYA 基于 Team Foundation Server、Octopus Deploy、PowerShell 和 Node.js 构建了这条交付路径。
BuildDirect 启动了一项 DevOps 和数字化转型计划，需要一条与之匹配的软件交付路径。公司的平台构建在 Microsoft 技术栈上，计划能否成功，取决于能否以可重复的方式把代码从开发者的提交一路送到生产环境。
BuildDirect 请 SEYA 的 DevOps 和云架构师协助设计这条路径。SEYA 评估了公司的目标和业务需求，在 Microsoft 技术栈上设计了一条交付流水线，并用 Team Foundation Server、Octopus Deploy、PowerShell 和定制的 Node.js 脚本端到端实施。
交付成果：
对 BuildDirect 交付目标和业务需求的评估，用于指导流水线设计
基于 Microsoft 技术栈的软件交付流水线设计
一条覆盖完整软件开发生命周期的 CI/CD 流水线：源代码管理和构建在 Team Foundation Server，发布编排在 Octopus Deploy
PowerShell 自动化和定制 Node.js 脚本，处理标准工具未覆盖的构建、打包和部署步骤
面临的挑战
当工具与组织不匹配时，DevOps 计划就会停滞。一个使用 Microsoft 技术栈的团队，从围绕其他生态设计的流水线中获益甚少；而只覆盖部分生命周期的流水线，会把手工步骤留在延误和失误真正发生的地方。
BuildDirect 需要一条自己的开发者每天都会使用的路径：把一次变更从提交经构建、测试到发布一路送达，中间没有交接，并且契合公司现有的工具和技能。计划的负责人也需要看到交付在实践中真正运转起来。
我们的专长
SEYA 从对 BuildDirect 目标和业务需求的深入评估开始。哪些应用必须流经流水线、发布如何审批、各环境有何差异、哪些步骤仍靠手工完成，这些都决定了设计。
基于这次评估，SEYA 在 Microsoft 技术栈上设计了一条交付流水线，选择的是 BuildDirect 工程师在合作结束后能够自己掌控的工具，而不是引入一套平行的工具链。
我们的方案
SEYA 实施了一条覆盖完整软件开发生命周期的 CI/CD 流水线。Team Foundation Server 托管源代码并运行构建，Octopus Deploy 按环境编排发布，其中包含 BuildDirect 所需的晋级和审批环节。
在现成工具力所不及的地方，SEYA 编写了 PowerShell 自动化和定制 Node.js 脚本，让原本需要手工完成的打包、配置和部署步骤成为流水线的一部分，每次都以同样的方式运行。
交付的价值
对 IT 经理或工程主管而言，变化在于精力的去向。部署不再是需要特定人员在场的事件，而成为团队中任何人都可以触发和追溯的流水线步骤。
由于流水线覆盖整个生命周期，什么内容由哪次提交构建、部署到了哪里，都有唯一的记录。当出了问题或某项功能需要在生产环境中验证时，审计人员、支持工程师或产品负责人要的正是这个。
构建在团队已在使用的工具之上，意味着合作结束后流水线可以由内部维护，这正是 DevOps 计划从一个项目变成一种工作方式的节点。
成果
BuildDirect 的开发者可以在他们已经在使用的 Microsoft 技术栈上，通过新流水线把功能从提交推进到发布。
这条流水线为公司的 DevOps 计划提供了一条可以继续构建的、切实可用的交付路径，构建、发布及配套自动化均以 Team Foundation Server、Octopus Deploy、PowerShell 和 Node.js 定义。
示意图：评估位于计划决策和流水线构建之间，因此工具链是为契合 BuildDirect 而选，而不是反过来。
示意图：四个部分显示为一条流水线；定制的 Node.js 脚本填补了标准 Microsoft 工具之间的空隙。
Microsoft 技术栈上的发布，还在依赖一份清单和某个人恰好在场？
SEYA 可以评估您的交付路径，并构建一条由您自己的团队运行的 CI/CD 流水线。发邮件至 hello@seyagroup.io 安排沟通。
联系我们
发送有关云、平台、数据或可靠性项目的咨询。营销邮件在表单中为单独选项。