3.构建错误是怎么来的
晓川在回到工位的路上,回想着跟老刘的谈话,心中感慨万千。老刘并不是去指责我,甚至不是命令或要求我,而是请我帮忙。对于我不成熟的想法,他没有贬低,甚至没有告诉我应该怎样做,而是让我继续想,提示我要多调查。
回到工位,晓川跟师父聊起这些。师父说:“老刘当然没法命令你了。他只是项目经理,不是你部门经理。他要是敢指责你,你就跟咱们领导说,有人给你撑腰。至于他不告诉你该怎么做,那要么是他也不知道,要么是他不愿意从他嘴里说出来。这人一看就是个老油条,你小心点儿。 ”
“谢谢师父提醒。 ”
都说公司里面有办公室政治,看来确实是这样啊,晓川心想。师父年长我很多,这方面我要多听听他怎么说。不过,到底为什么构建总是出错呢?老刘说得也对,我得调查分析一下才能知道。
晓 川着手调查。就以上个星期刚做完的集成为例吧。每次构建出错,我是定位到出错的源文件,然后通过源代码版本控制工具查一下这个文件昀近是谁动过,然后就找 相应的程序员去改正,然后把改正直接检入到集成分支。嗯,那我去看一下在集成期间,是谁把改正检入到集成分支上的,就能知道是谁的提交造成了问题。
晓川去查看源代码版本控制工具的版本库中集成分支上昀近所做的改动。咦,都是晓川改的……哦,是因为程序员都是跑到我的计算机上改的,所以都是以我的名义检入的。唉,这么查,查不出来了。
晓川只好根据每次改动所改的具体文件去查。因为修改这个文件,让编译能通过,那意味着这个文件的前一次改动是有问题的。这样,再去查这个文件当初是谁在哪个任务分支上改的,就能知道是谁在哪儿惹的祸了。
就这样,晓川用了大半天的时间,到快下班的时候,整理出了一张表,表明这次集成遇到的每个构建错误,各是由谁,在哪个提交中带进来的。下班啦!
下了班,晓川在外面随便买了点东西吃。吃着吃着,觉得不对劲儿。倒不是吃的东西不对劲儿,而是想起了自己下班前的工作成果,觉得不对劲儿。
每 个构建错误,确实是某个提交带来的,确实是因为某个提交的存在而存在的。如果没有那个提交,就没有相应的构建错误。但是,这并不能说,这个提交本身是有问 题的,是有构建错误的。因为程序员在提交前构建的内容,并不是我构建的内容。我构建的内容,是多个提交合并到一起之后的内容。
事实上,这正是老刘质疑我的地方。“如果程序员的提交都没问题,你确定你构建的时候就肯定没问题么?”我那时也觉得有点不对劲儿,自己的思路不严谨。怎么今天下午调查的时候又给忘了!不成,我得继续研究清楚。不然一周后,新的一轮构建又要开始了,就顾不上了。
星期二上班,晓川来到工位,解锁计算机,开始复现程序员在提交前的环境。这个比较简单,因为程序员工作在任务分支上,在提交前把所有要提交的内容都保存在任务分支上,所以,只要把任务分支末端的源代码取出来,放到本地工作区里,就得到程序员在提交前的环境了。
在这样的工作区里,晓川开始编译构建。构建要一个多小时的时间,因为没法做增量构建,只能全量构建。一个多小时后,构建结果出来了,构建是成功的!
晓川又做了几个试验。结果不尽相同。有的是成功的,有的报错。虽然不能完全确定,但是凭记忆,应该就是在集成分支上构建时报的错。这么说,集成分支上构建报错,有两种可能,一种是提交本身的问题,一种是几个提交相互合并带来的问题。在数量上,大概是一半儿一半儿。
得 到了分析结果,晓川觉得挺有成就感。高兴的时候想想,嗯,集成这工作呢,其实也挺轻松的,因为大部分时间都在等。等着程序员解决代码合并冲突,等着构建。 构建失败了,等着相关的程序员修复。而有时候是大家一起陪着等。等着把提交的代码都合并到集成分支,相关的程序员们才能回家。等出了基线,依赖于基线中内 容的新的任务才能开始。等着等着,时间就等过去了。青春就等过去了。
本文节选自《软件集成策略》一书
董越 著.
电子工业出版社出版。
相关推荐
最后,由于版图设计的复杂性,通常需要借助专业软件来辅助设计和验证。现代的电子设计自动化(EDA)工具能够提供从逻辑设计、电路仿真、版图设计到掩模生成等一系列集成解决方案。这些工具大大简化了版图设计的过程...
Abstruse - 使用Node.js和Docker构建的持续集成平台
遵循《计算机软件开发规范 GB 8566-88》,可以有效减少开发过程中的错误和返工,提高软件的可维护性和可扩展性,同时也有助于提升团队的协作效率,降低项目的整体成本。 总结,GB 8566-88规范是软件开发过程中的...
在软件开发过程中,通常先进行单元测试,确保每个独立的模块都能正常工作,然后通过集成测试来验证这些模块之间的交互是否符合预期。 #### 二、基于分解的集成测试方法 ##### 1. 大爆炸集成 **目的**:尽可能缩短...
### 软件测试-集成测试指南 #### 1. 简介 ##### 1.1 目的 本文档旨在提供一个详尽的指南,帮助项目开发人员理解并执行软件集成测试的过程。集成测试作为软件开发生命周期中的一个重要阶段,确保各个独立的模块在...
集成开发环境是程序员进行软件开发的主要工作平台,它整合了代码编辑器、编译器、调试器和各种辅助工具,提供了一站式的编程解决方案。TPC-ZK-II正是这样一款为微机程序设计定制的IDE,旨在简化开发流程,提高开发...
1. **持续集成(CI)**:CI是开发过程中的自动化流程,它要求开发者频繁地将代码提交到共享仓库,并立即通过自动化构建和测试来验证新代码的质量。蓝盾bk-ci提供了一个平台,使得每次代码提交都能触发构建和测试,...
Hudson是一种开源的持续集成工具,旨在自动化软件开发过程中的构建、测试及部署等环节。通过Hudson,开发者能够实现自动化的构建流程,确保代码质量的同时提高开发效率。本书《Continuous Integration with Hudson》...
持续集成(Continuous Integration,简称CI)是一种软件开发实践,要求开发人员经常性地将代码提交到共享仓库中,每次提交后都会自动运行构建和测试流程。这种方法能够尽早发现集成错误并减少人工干预的需求,从而...
持续集成是一种软件开发实践,它提倡频繁地将代码变更集成到主分支,以尽早发现并修复错误。CruiseControl是一款开源的持续集成服务器,版本2.7.3提供了自动化构建、测试和部署的功能,帮助团队高效协作,确保软件...
在Java开发领域,Maven和Jetty是两个非常重要的工具。Maven是一个项目管理工具,它可以帮助开发者管理和构建Java项目...在选择版本时,应根据项目的具体需求和环境来决定,同时关注插件的更新,以获取最佳的开发体验。
每次集成都通过自动化构建(包括编译、运行测试和其他质量检查程序)来验证,从而尽早发现集成错误和冲突,提高软件质量并降低风险。本文将详细介绍持续集成的重要知识点。 ### 持续集成的实践原则: 1. **维护一...
**UAP-STUDIO 集成开发环境与Eclipse插件详解** UAP-STUDIO(统一应用平台工作室)是一款强大的企业级应用开发工具,它提供了一整套完整的开发、调试、部署解决方案,旨在提高开发效率并降低开发复杂度。Eclipse,...
每次集成都会通过自动化构建过程来进行验证,该过程包括编译、发布以及自动化测试等步骤,目的是尽早发现集成错误。 **持续集成的主要目标**: - 减少构建失败的次数并不是其核心目的; - 尽早发现问题,缩短问题...
Jenkins mavn git docker-compose swarm 构建持续集成及一键式部署
在提供的压缩包`cas-overlay-template-5.3.zip`中,我们找到了CAS 5.3版本的源代码模板,这将帮助开发者快速构建自己的CAS服务器,并与Spring Boot集成。下面我们将详细讨论如何理解和利用这些资源。 首先,`cas-...
### UIR高校管理信息化平台软件用户手册核心知识点 #### 一、软件介绍与组成 - **产品名称**:UIR高校管理信息化平台软件 - **发布机构**:常州大学UIR软件项目组 - **发布时间**:2010年5月 - **重要声明**: - ...
- **3.2.1 集成构建**:执行定期或按需的构建,以合并和测试新的或更新的组件。 - **3.2.2 集成测试**:执行各种集成测试,如组件接口测试、系统测试,确保组件间交互的正确性。 **3.3 监控和控制产品集成** - **...