应对待构建错误时应注意的问题
2017-10-31 17:28:33 | 来源：中培企业IT培训网
构建服务器可以随心所欲地传递出错误和代码质量问题的信号，如果开发团队不关心这些问题，那么这些通知和可视化的投资收益为零。
对此，中培技术专家袁老师认为，这并不是技术本身可以解决的。流程需要每个人都同意，让人人都能看见自己参与所带来的利益是达成共识的最简方法。
问题是企业里总是有一大堆迫在眉睫的事。构建错误会比产品错误更重要吗？还有代码质量指标方面，如果改进代码质量需要数年，值得着手解决这个问题吗？
我们怎样解决这类问题？这里有一些想法：
不要过分追求代码质量指标。可以先减少测试的数量，直到代码质量报告达到了可以修复的水平。解决之后再把测试加回来。
定义问题的优先级。产品问题优先，然后才是构建错误。在问题被完全解决之前，不要在损坏的代码之上提交新代码。
尽管想让构建服务器成为持续交付流水线的中心之一，但我们也要考虑当构建服务器瘫痪的时候，构建和部署的流程不应该停滞不前。为此，构建本身应该尽可能健壮，并且可以在任何主机上重复工作。
这对像Maven那样的一些构建来说相当容易。可即便如此，一个Maven构建也可能有无数的缺陷而使其无法被正常移植。
一个基于C语言的构建会很难移植，如果你没有幸运到所有的依赖都在操作系统库里可用的地步。还是那句话，健壮性通常能够值回票价。
总结
我们快速扫过了构建代码的系统。看过了用Jenkins构建持续集成服务器，也检查了许多可能发生的问题，DevOps工程师的生活总是很有意思，但并不总是很容易。
想了解更多IT资讯，请访问中培伟业官网：中培伟业
- 上一篇：详解IT服务管理理念的导入
- 下一篇：ITIL中级，助您成长为行业精英人才
400-626-7377
录播
公开课
题库
在线咨询