连续产品有许多内置的 UI 插件,允许团队跟踪从提交到生产的一组故事和缺陷,有没有办法通过 API 完成这项工作,以帮助它与已经存在的管道集成Jenkins 还是 Azure DevOps?
1 回答
虽然这有点难以回答,但由于开发工作流程通常如此不同,有几个 API 可用于促进各种工作流程。
最低限度
Continuum 严重依赖于来自 VCS 的遥测,因此至少要设置一个从您的 VCS(GitHub、GitLab、BB 等)到 Continuum 中定义的项目的 webhook。这将允许 continuum 将代码库的更改与您选择的计划系统(VersionOne、Jira、ADO 等)中的“更改动机”(工作项)关联起来
将 VCS 推送发送到 Continuum 的简单行为会激活大量价值 - 从 Rogue Commit 意识到风险分析。
使用管道
pipeline
很多时候,即使已经存在其他构建自动化,价值流设计师也会触发 Continuum 。(Continuum 管道具有许多其他纯自动化 devops 工具中并不总是可用的功能和集成。)以这种方式完成时,Continuum 管道通常wait for data
来自外部进程。使用此端点,外部进程可以在完成时发出信号,而 Continuum 将继续其规定的路径。
另一种常见的方法是将 Continuum 项目配置为stage
提交和工作项,以便后续管道运行由现有的外部自动化触发。在这种情况下,在 VCS 推送中接收到的数据清单已设置并准备好运行,等待来自外部作业的简单触发。
使用包
在更成熟的情况下,当价值流在 Continuum 中完全定义时,您将需要接受 Package Progression 的概念。一种更高级别的分组机制,pipeline
远高于简单的“构建管道”,它Package Progression
是一个产品的完全定义的工作流和版本管理过程,包括捕获“devops”域之外的手动活动的能力,并生成全面的流量指标。使用包时,有几个 API 很有价值。
如果外部自动化创建了一个实际上有机会成为生产候选版本的构建工件,请使用此 API 告诉 Continuum 注册revision
该包的新版本。
在外部自动化更全面的情况下,甚至可能将工件部署到生产版本的目的地,使用此 API 来让 Continuum 在工件在其过程中逐渐成熟时随时了解情况,这样它就可以保持流量指标的准确性。
最后,如果您现有的自动化已经如此完整,可以实际进行正式的生产部署,请使用此 API 通知 Continuum 修订版已delivered
发送给消费者 - 它的旅程已经结束。
还有一些 API 有助于监控/管理 Package Progression 过程:
给定使用 创建的修订new_revision
,您可以查询它manifest
(提交、工作项和与之关联的工件的列表。
如果您的 Progression 实现手动活动(例如,您需要手动触发一些自动化流程),则此 API 可以以编程方式完成该活动。
同样,如果您正在Controls
为审计和合规性报告进行捕获,则外部流程可以告诉 Continuum 控制已得到满足,从而允许继续进行。
对包修订的当前状态感到好奇吗?这将返回有关其在价值流中当前位置的详细信息。
对包修订的历史感到好奇?这将通过价值流返回有关修订历史的详细信息。
完整的 API 文档可以在这里找到。
如果您想聊天,我们很乐意详细讨论 - support@versionone.com