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