敏捷实践 持续集成 2.0

Will · 2020年06月10日 · 71 次阅读

根据「百度百科」的定义

持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

重点

编辑发布自动化测试
常见的 CI 软件工具或平台主要覆盖这三个阶段

变化

如今敏捷开发的「兴起」,很大程度上对于持续集成这个模式提出了更高的要求,倘若仍旧停留在 编译、发布、自动化验证 这三个阶段,对于敏捷而言,只是做到了 局部 敏捷,而不是项目/产品敏捷。

因此,要达到真正的 项目/产品敏捷 ,至少要包含以下几阶段:

需求管理编码单元测试代码扫描编译发布自动化测试质量评估

解决方案

有人期望用 JIRA/禅道 这样的工具来完成 需求、缺陷、测试用例 的集中式管理,只能说效果一般般,并且 TA 无法解决全阶段的覆盖。

有人期望用 Jenkins 这样的工具来完成 单元测试、代码扫描、编译、发布、自动化测试,但 TA 完成的只是持续集成中的很小的几个阶段,不用觉得包含了 5 个阶段,就获得了整个 CI,其实差得还很远。

技术层面能解决的,一定是金字塔的最底层。

金字塔中端和顶端的那些,很大程度上仅靠技术是无法解决的,更多的需要经验的传承。

把经验抽象成解决方案,是 持续集成 2.0 的突破点。

抛开工具看本质,当我们不再依赖工具,思考如何徒手解决这些阶段,可能会有不一样的收货。

很多 DevOps 平台对于业务而言,比 Jenkins 的流水线更友好,有些加入了组织权限流程的设计,使其不仅仅是个 CI 工具,但仍旧无法覆盖 持续集成 2.0 的所有阶段。即使现在已有的平台都覆盖全了,也未必实现真正的 持续集成 2.0,因为 TA 们只提供了技术的解决方案。

而真正的 持续集成 2.0 需要提供一个会思考、会判断的指导。

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册