管道演进：从三条管道到一条MVP当客户向我们寻求数字化转型的帮助时，我们会用一条简单的信息开始这一过程："我们可以做您要求我们做的任何事情。"然而，随着我们完成售前流程并开始定义客户实际需要什么，我们提供的往往与他们最初的期望大不相同。不同的团队有不同的需求，但更多的时候他们有非常相似的需求，但他们并不知道。有时候，他们真的不知道自己需要什么，除了无需焦虑就可以发布软件。那么，在客户根据业务需求发布软件的过程中，从A点到Z点的过程是什么？一个最小可行的管道（MVP）——它允许在最短的时间内装载绝大多数的应用程序，但给它们灵活性，可以根据需求的变化调整或重构管道。以下是我们最近与一家大型连锁酒店的谈话演变的一个主要例子。请记住，不是每个顾客都是一样的。然而，在现实中，它们都是一样的：它们都有自己的变化和挑战，但大多数都会陷入相同的方式思考。三团队，三条流水线运行实施前研讨会是我们专业服务组织的一项关键职能。研讨会将概念验证细节与解决方案实施的实际情况隔离开来。研讨会旨在从客户那里提取更多信息，并找出"上线"策略是什么。最终，为了成功，我们希望我们的解决方案能够在生产中蓬勃发展。当我们第一次开始规划他们的管道需求时，我们最终得到了三个不同的管道——这仅仅是个开始！下面的图片显示，这些管道完全是根据与不同团队的对话而设计的。在本例中，我们从第一个团队和第一个确定的应用程序"GTP（投入生产）App1"开始，它产生了以下管道。正如你所看到的，虽然很初级，但这是一个很好的起点。这不仅引起了团队之间的对话，而且在团队成员意见不一致时引发了激烈的争论。我们讨论的第二条管道是针对他们的CRM（后端技术）。工作流程没有太大的不同，但是这个特定的团队坚持认为它与其他团队有很大的不同，因此需要自己的管道。提取这些信息是一项挑战，但对于了解该群体的显著差异和需求至关重要。每个人都要保持开放的心态，这是解决这一经常引起争议的最好办法步骤。那个我们想帮助开发的第三条管道是为他们的移动系统开发的。有趣的是，移动系统组没有管道方面的经验，也没有将应用程序"实例化"到cloudbeesflow中的经验。他们的管道图不过是讨论的要点。当我们启动一个实施Evolution Beginthus开始了对所有团队的再教育和开发管道的过程。我们期望这些管道的开发会很有趣，如果没有别的，但我们知道我们必须从某个地方开始。因为客户不清楚从哪里开始，我们从第一天开始就意识到，尽管进行了持续的对话并充实了大部分技术细节，尝试串联开发多个管道或尝试开发单个管道（MVP）将是困难。实施我们从推荐MVP开始实施。这种方法帮助团队（CloudBees和客户）开始寻找一种更具凝聚力的方法来创建一个满足80-85%应用程序需求的管道。总会有一些边缘案例，因此我们计划在稍后处理这些案例，因为客户的团队利用CloudBees Flow建立了他们的专业知识。这里的快速胜利是从重新创建一个现有的Jenkins管道开始的，该管道满足了他们的大部分应用程序。这是一个很好的起点，因为它处理的是典型的构建-->发布-->部署-->测试方法。我们要做的是在中间插入cloudbeesflow所做的"酷"事情。下面是最初建模的詹金斯管道出去。跟着在最初的设计中，客户认为有必要建立一个适当的工作流程，这样应用程序负责人就可以向他的同事和应用程序开发团队解释管道在做什么。正如您所看到的，这使得设计三个阶段的MVP变得很容易，INT（集成）、STAGE和PROD。简而言之，这就是创建MVP所需要的。整个过程中最酷的事情是他们的团队是MVP设计的始作俑者，而不是我们。集成包括但不限于：服务NowJenkinsArtifactoryCA Agile Central（Rally）。这是由客户提出的MVP.三团队，一个最小可行的流水线下面的图像突出显示了MVP的第一个版本（1.0）。它满足了客户对所有三个应用程序的初始实施计划，并使它们有望在2019年底实现100多个应用程序的上线。故事的寓意是，MVP是一个概念和解决方案，为各种规模的客户提供了高成功率，因为它：为客户提供了一个路线图，让他们从正确的管道开始发展。使客户可以从开始。给予实施团队，预先商定的目标，以及一个伟大的开始点。减少在一个实现周期中，多用例开发的混乱会占用大量的时间和浪费大量的周期。----------------------------------------------------------------------------------------------------------请继续关注类似的故事。您也可以订阅我们的博客，并在这里了解CloudBees的最新消息。