`

软件集成策略故事连载----构建错误是怎么来的

阅读更多

 

3构建错误是怎么来的


    晓川在回到工位的路上,回想着跟老刘的谈话,心中感慨万千。老刘并不是去指责我,甚至不是命令或要求我,而是请我帮忙。对于我不成熟的想法,他没有贬低,甚至没有告诉我应该怎样做,而是让我继续想,提示我要多调查。

回到工位,晓川跟师父聊起这些。师父说:老刘当然没法命令你了。他只是项目经理,不是你部门经理。他要是敢指责你,你就跟咱们领导说,有人给你撑腰。至于他不告诉你该怎么做,那要么是他也不知道,要么是他不愿意从他嘴里说出来。这人一看就是个老油条,你小心点儿。

谢谢师父提醒。

都说公司里面有办公室政治,看来确实是这样啊,晓川心想。师父年长我很多,这方面我要多听听他怎么说。不过,到底为什么构建总是出错呢?老刘说得也对,我得调查分析一下才能知道。

晓 川着手调查。就以上个星期刚做完的集成为例吧。每次构建出错,我是定位到出错的源文件,然后通过源代码版本控制工具查一下这个文件昀近是谁动过,然后就找 相应的程序员去改正,然后把改正直接检入到集成分支。嗯,那我去看一下在集成期间,是谁把改正检入到集成分支上的,就能知道是谁的提交造成了问题。

晓川去查看源代码版本控制工具的版本库中集成分支上昀近所做的改动。咦,都是晓川改的……哦,是因为程序员都是跑到我的计算机上改的,所以都是以我的名义检入的。唉,这么查,查不出来了。

晓川只好根据每次改动所改的具体文件去查。因为修改这个文件,让编译能通过,那意味着这个文件的前一次改动是有问题的。这样,再去查这个文件当初是谁在哪个任务分支上改的,就能知道是谁在哪儿惹的祸了。

就这样,晓川用了大半天的时间,到快下班的时候,整理出了一张表,表明这次集成遇到的每个构建错误,各是由谁,在哪个提交中带进来的。下班啦!

下了班,晓川在外面随便买了点东西吃。吃着吃着,觉得不对劲儿。倒不是吃的东西不对劲儿,而是想起了自己下班前的工作成果,觉得不对劲儿。

每 个构建错误,确实是某个提交带来的,确实是因为某个提交的存在而存在的。如果没有那个提交,就没有相应的构建错误。但是,这并不能说,这个提交本身是有问 题的,是有构建错误的。因为程序员在提交前构建的内容,并不是我构建的内容。我构建的内容,是多个提交合并到一起之后的内容。

事实上,这正是老刘质疑我的地方。如果程序员的提交都没问题,你确定你构建的时候就肯定没问题么?我那时也觉得有点不对劲儿,自己的思路不严谨。怎么今天下午调查的时候又给忘了!不成,我得继续研究清楚。不然一周后,新的一轮构建又要开始了,就顾不上了。

星期二上班,晓川来到工位,解锁计算机,开始复现程序员在提交前的环境。这个比较简单,因为程序员工作在任务分支上,在提交前把所有要提交的内容都保存在任务分支上,所以,只要把任务分支末端的源代码取出来,放到本地工作区里,就得到程序员在提交前的环境了。

在这样的工作区里,晓川开始编译构建。构建要一个多小时的时间,因为没法做增量构建,只能全量构建。一个多小时后,构建结果出来了,构建是成功的!

晓川又做了几个试验。结果不尽相同。有的是成功的,有的报错。虽然不能完全确定,但是凭记忆,应该就是在集成分支上构建时报的错。这么说,集成分支上构建报错,有两种可能,一种是提交本身的问题,一种是几个提交相互合并带来的问题。在数量上,大概是一半儿一半儿。

得 到了分析结果,晓川觉得挺有成就感。高兴的时候想想,嗯,集成这工作呢,其实也挺轻松的,因为大部分时间都在等。等着程序员解决代码合并冲突,等着构建。 构建失败了,等着相关的程序员修复。而有时候是大家一起陪着等。等着把提交的代码都合并到集成分支,相关的程序员们才能回家。等出了基线,依赖于基线中内 容的新的任务才能开始。等着等着,时间就等过去了。青春就等过去了。

本文节选自《软件集成策略》一书

董越
.
电子工业出版社出版。

0
2
分享到:
评论

相关推荐

    计算机软件开发规范 GB 8566-88

    遵循《计算机软件开发规范 GB 8566-88》,可以有效减少开发过程中的错误和返工,提高软件的可维护性和可扩展性,同时也有助于提升团队的协作效率,降低项目的整体成本。 总结,GB 8566-88规范是软件开发过程中的...

    软件工程中的系统集成与测试策略

    一个高效的集成与测试策略能够显著减少开发过程中的错误与缺陷,从而确保软件产品能够按时完成并达到预期的质量标准。 **软件集成的定义与分类** - **模块化集成**:这是一种将独立开发的模块按照一定的顺序和逻辑...

    极光推送JAVA服务端集成 jpush-api-java-client-master

    【极光推送JAVA服务端集成 jpush-api-java-client-master】是一个专门为Java开发者设计的极光推送(JPush)服务端SDK。极光推送是面向移动应用开发者提供的一套消息推送服务,它可以帮助开发者轻松实现向Android、...

    Python-蓝盾bkci是一个开源的持续集成和持续交付系统

    1. **持续集成(CI)**:CI是开发过程中的自动化流程,它要求开发者频繁地将代码提交到共享仓库,并立即通过自动化构建和测试来验证新代码的质量。蓝盾bk-ci提供了一个平台,使得每次代码提交都能触发构建和测试,...

    持续集成(CruiseControl-2.7.3)

    持续集成是一种软件开发实践,它提倡频繁地将代码变更集成到主分支,以尽早发现并修复错误。CruiseControl是一款开源的持续集成服务器,版本2.7.3提供了自动化构建、测试和部署的功能,帮助团队高效协作,确保软件...

    软件集成.0.8

    ### 软件集成.0.8:如何做软件开发中的持续集成,提高软件质量 #### 关键知识点 **一、软件集成的概念** 1. **组装集成与合并集成:** - **组装集成:** 指的是将独立开发的模块或者组件组合在一起形成完整的...

    车载软件架构 - 持续集成持续交付 软件交付敏捷开发

    车载软件架构在现代汽车行业中的重要性日益凸显,尤其是在持续集成持续交付(CI/CD)的实践上。CI/CD 是一种提升软件开发效率和质量的方法,通过自动化流程确保软件的频繁迭代和稳定交付。在车载软件领域,由于其...

    UAP-STUDIO 集成开发环境eclipse插件

    **UAP-STUDIO 集成开发环境与Eclipse插件详解** UAP-STUDIO(统一应用平台工作室)是一款强大的企业级应用开发工具,它提供了一整套完整的开发、调试、部署解决方案,旨在提高开发效率并降低开发复杂度。Eclipse,...

    使用Hudson持续集成 ppt

    - **定义**:持续集成(Continuous Integration, CI)是一种软件开发实践,开发者经常将代码提交到共享存储库,每次提交后都会自动构建并进行自动化测试,以尽早发现集成错误。 - **核心价值**: - **持续反馈**:...

    软件测试与持续集成技术教程.pptx

    ### 软件测试与持续集成技术教程 #### 第1章 软件测试与持续集成技术介绍 **软件测试概述** - **定义**: 软件测试是对软件应用程序进行实际测试的过程,目的是确保软件的质量和可靠性。 - **重要性**: 通过软件...

    软件工程与软件集成与配置管理.pptx

    - **持续集成**:频繁地将代码合并到主分支,自动进行构建和测试,以确保软件质量。 - **自动化测试**:利用自动化工具进行测试,提高测试效率和准确性。 **软件工程挑战**: - **复杂性控制**:随着软件规模的增长...

    CMMI集成培训问答

    - **策略**: 递增集成策略是一种常见的方法,逐步将模块加入到系统中,每次添加一个模块后进行测试。 - **顺序**: 通常先构建系统的基本框架,再按需集成各个功能模块。 - 例如,首先搭建系统平台框架,然后依次...

    Android-GreenBuild用于管理CI构建的Android应用程序

    在Android应用开发领域,持续集成(Continuous Integration, CI)是一个重要的实践,它有助于开发者快速发现并修复代码中的问题,提高软件质量。而“Android-GreenBuild”正是一款专为管理Android应用程序CI构建而...

    计算机软件开发规范_GB_8566-88

    6. **组装测试**:对软件组件进行集成测试,确保各部分协同工作。 7. **确认测试**:验证软件是否符合最初的需求规格。 8. **使用和维护**:软件部署后持续的维护和支持服务。 #### 三、软件开发方法 GB_8566-88中...

    java持续集成 持续集成

    Java持续集成是软件开发过程中的一个关键实践,它旨在频繁地合并开发人员的代码更改,以便尽早发现并解决潜在的问题。这个过程通过自动化构建、测试和部署,确保代码的质量和项目的稳定性。持续集成(Continuous ...

    软件工程的持续集成与部署.pptx

    持续集成是一种软件开发实践,指的是开发者频繁地(通常是每天)将他们的代码更改合并到一个共享的主分支中,并通过自动化构建和测试来验证新提交的代码是否导致了任何问题。这种做法有助于早期发现问题,减少集成时...

Global site tag (gtag.js) - Google Analytics