哈哈，想不到吧，虽然经过小伙伴的很长时间的努力，我们最终落地的效果是不理想。最终项目被”砍“掉了。不过很值得和大家分享下，感觉这篇应该是这个系列最值钱的一篇啦，不容错过！
1、持续交付最终结果
在完成试点后，整体落地推进整体结果不是很好，总结两句话
- Web端使用体验很操作
- 移动端整体尚可
最终由于**”领导层“**的决定，禅道寿终正寝了 😢😢😢
2、失败原因
其实在禅道命运的变更和我司上层调整是一个重合的时间节点，当初我一度很”郁闷“，想不通这个是一个正确的事儿，K8s也是前沿趋势，我门打造的可是我司第一个统一产研研发大平台……
但是随着时间推移和经历更多的DevOps的实践，发现禅道的”死亡“一定程度上是必然的，我会逐步给到各位解释哈。
2.1、空中楼阁（核心原因）
我们打造的持续交付系统可能先对于公司当时的现状来说太”高、大、尚“了，因为技术层面整体 底层建设不牢
- 软件版本和架构未标准化 – 容器化改造能定制化到你怀疑人生
- 运维自动化程度低（基本处于脚本时代吧） – 配置改造、域名标准
- 无标准化测试环境 – 大家各自的测试环境基本各成体系
- 自身建设的K8s集群先对稳定性不足
- 大部分小伙伴其实都没有准备好
基建其实是一个很庞大的工程，不是一个持续交付系统所能撑起来的，我基于个人的理解把它们理解成一套房子，而持续交付属于Roof一环，如果Foundation和House都没有建设好的化，直接盖”屋顶“，这将是一个很艰难的过程。
2.2、技术选型
并不是最新、先进就是合适的，我觉得当时起步选择了Helm并不是一个明知的决定，学习成本太高，专业技术方向人员还Ok，当时需要推向多有业务小伙伴使用，这个成本可想而知，入门成本同时带来的问题就是维护起来也是一个浩大的工程。
2.3、自身易用性
我们基于禅道自身Scrum框架，做了很多流程、角色限制，最终的结果感觉就是作茧自缚。说实话这个就是机械的贯彻了标准的软件生命周期流程（也可以理解为瀑布式），然而他并不”敏捷“。
流程过度的自由，会引发不可预知的问题，但流程机械化的强制管控，会引起生产效率的降低以及怨声载道。在流程和效率中间找到一个平衡，或者说DevOps落地的不同阶段我们可以逐步规范，这估计也是 敏捷思想 想引导的，可惜的是：当时的我们并不知道这些（认知局限）