构建服务器可以随心所欲地传递出错误和代码质量问题的信号，如果开发团队不关心这些问题，那么这些通知和可视化的投资收益为零。

对此，中培技术专家袁老师认为，这并不是技术本身可以解决的。流程需要每个人都同意，让人人都能看见自己参与所带来的利益是达成共识的最简方法。

问题是企业里总是有一大堆迫在眉睫的事。构建错误会比产品错误更重要吗？还有代码质量指标方面，如果改进代码质量需要数年，值得着手解决这个问题吗？

我们怎样解决这类问题？这里有一些想法：

不要过分追求代码质量指标。可以先减少测试的数量，直到代码质量报告达到了可以修复的水平。解决之后再把测试加回来。

定义问题的优先级。产品问题优先，然后才是构建错误。在问题被完全解决之前，不要在损坏的代码之上提交新代码。

尽管想让构建服务器成为持续交付流水线的中心之一，但我们也要考虑当构建服务器瘫痪的时候，构建和部署的流程不应该停滞不前。为此，构建本身应该尽可能健壮，并且可以在任何主机上重复工作。

这对像Maven那样的一些构建来说相当容易。可即便如此，一个Maven构建也可能有无数的缺陷而使其无法被正常移植。

一个基于C语言的构建会很难移植，如果你没有幸运到所有的依赖都在操作系统库里可用的地步。还是那句话，健壮性通常能够值回票价。

总结

我们快速扫过了构建代码的系统。看过了用Jenkins构建持续集成服务器，也检查了许多可能发生的问题，DevOps工程师的生活总是很有意思，但并不总是很容易。

想了解更多IT资讯，请访问中培伟业官网：中培伟业