博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
太多脚本将会毁掉持续交付
阅读量:6366 次
发布时间:2019-06-23

本文共 819 字,大约阅读时间需要 2 分钟。

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

\\

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

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

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

\\

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

\\

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

\\

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

\\

查看英文原文

转载地址:http://mprma.baihongyu.com/

你可能感兴趣的文章
去除UITableViewheader footer黏性
查看>>
windows2003 iis6.0不能显示asp.net选项
查看>>
xen MacOS
查看>>
如何学好C和C++
查看>>
Gitlab通过custom_hooks自动更新服务器代码
查看>>
我的友情链接
查看>>
python 如何判断调用系统命令是否执行成功
查看>>
Lesson10 vSphere 管理特性
查看>>
memcache 扩展和 memcached扩展安装
查看>>
好程序员的查克拉---自信
查看>>
线程池的设计(二):领导者追随者线程池的设计
查看>>
获取设备列表
查看>>
Django使用网上模板做个能展示的博客
查看>>
基于同IP不同端口,同端口不同Ip的虚拟主机 基于FQDN的虚拟主机
查看>>
项目软件集成三方模块,编译中int32和uint32定义冲突解决方法
查看>>
StretchDIBits速度测试(HALFTONE)
查看>>
在.NET Workflo“.NET研究”w 3.5中使用多线程提高工作流性能
查看>>
验证Oracle处理速度
查看>>
自己写一个jquery
查看>>
艾伟:C#中抽象类和接口的区别
查看>>