太多脚本将会毁掉持续交付

阅读数:751 2018 年 6 月 25 日

话题:重构DevOps持续交付语言 & 开发

Electric Cloud 的产品经理 Avantika Mathur 在上个月的伦敦 Continuous Lifecycle大会上呈现了演讲,谈到了与持续交付管道中越来越多的脚本相关的成本。除了维护成本,在将变更部署到生产环境之前,正在进行的活动缺乏可见性和可审计性也是另一个主要成本,但很多组织都没有意识到这一点。

要解决这个问题,首先需要识别问题,并为管道编配制定指导原则。Mathur 推荐了这些原则:

  • 确保部署之间的可重复性和一致性
  • 将应用程序的定义与环境分开
  • 专注于环境之间的可移植性
  • 避免锁定某些工具和技术(换句话说,确保通过实践来指导工作,而不是工具)

在避免脚本蔓延方面,Mathur 建议的方法是首先将脚本重构为参数化的通用函数,然后在可能的情况下用可以完成相同甚至更好工作的工具替换它们。

不过,同时处理大量脚本可能具有一定挑战性(从技术和人员的角度来看),并且效率低下(低投资回报率)。Mathur 推荐了一种迭代方法。首先,通过价值流映射来识别那些减缓交付或混淆交付流程的中间瓶颈和依赖。这将有助于优先考虑哪些脚本需要首先重构。Mathur 还建议对现有脚本进行分桶(配置、部署、测试自动化等)以便识别出重复任务,根据复杂性对它们进行分类以评估工作量,测算脚本运行的频率以估计潜在收益,最后再看看是否存在更好的替代方案可以降低成本。

Mathur 最先注意到这种“脚本噩梦”的影响,80%的团队工程时间用在了维护(而不是用于演进)或低效自动化的脚本以及缓慢的流程上,而不是用于更快更安全地进行交付。工程师忙于维护脚本,害怕更改脆弱的脚本,执行内容缺乏可见性,冗长的审计准备流程,这些都是脚本失去控制或管道编配工作不够细致的典型现象。

总之,Mathur 建议“将管道作为一种产品对待”,确保管道上的每一次变更都经过测试,并在进入“生产”环境之前经过全面评审(即可供所有人使用)。这也意味着要让每个人都能看到管道,通过度量和基准来改进性能,并尽可能重用已有的部分。

查看英文原文Too Many Scripts Can Kill Your Continuous Delivery