BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Manuel Pais 关注 9 他的粉丝 ,译者 无明 关注 0 他的粉丝 发布于 2018年6月26日. 估计阅读时间: 2 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

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

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

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

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

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

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT