《配置管理最佳实践》——2.11 持续集成与每日构建

2.11 持续集成与每日构建

持续集成是一个相当流行的软件开发实践。现在,人们时常把持续集成和敏捷开发联系到一起。实际上,即使开发团队使用的不是敏捷开发的过程, 持续集成在他们之间也已经非常流行。另外一个很明显的现象是很多研发团队并不需要签入构建(commit build, check-in build),也就是说并不需要每次有代码签入代码库都要立刻触发一个构建。很多时候,每日构建已经足够用了,而且也容易实现。持续集成经常会发起很多没必要的失败构建,导致显示面板上出现很多没必要的失败记录。某些构建可能需要几个小时才能完成,这时持续的构建就会导致一个很长的构建队列,最终使有些构建无法完成。在我工作过的公司,我认为选择每日构建可能会更好。我的观点是尽可能采取更轻量级的流程。恰好够用的过程改进是我最推崇的,这也是建立有效开发过程最实际最直接的方法。

时间: 2024-07-28 22:47:02

《配置管理最佳实践》——2.11 持续集成与每日构建的相关文章

《配置管理最佳实践》——导读

** 前言 **配置管理(CM,Configuration Management)在任何开发工作中都起着非常关键的作用.我从事配置管理的实施和支持工作已经超过25年,本书中将讨论的大部分内容都直接来自于个人的经验.我实施并支持过各种配置管理的实践方法并达到这样一种状态--如果建立的过程或自动化没有按照预期般运作的话,我经常会在半夜里被惊醒.作为一名教师,我向超过九百多的专业技术人员传授过工业级的配置管理工具(同样,他们在成功地完成课程后都得到了我家的电话号码,这样如果我没有教授好知识和技能,即使

《配置管理最佳实践》——2.10 建立构建过程

2.10 建立构建过程 实施构建工程最佳实践是一项非常具有挑战性的工作.构建工程师可以选择有益于公司的实践:也可以选择最好的工具去建立可重复的构建,实施持续集成.但是实际工作远不止此,构建工程部门还需要为开发团队提供培训和技术支持.我的经验是和研发团队合作,解决构建和部署过程中的问题,然后转到幕后做支持,把日常的工作还交给开发团队来负责.这里有个前提就是公司的合规部门允许这样做.曾经一家实施 SAS-70的公司认为可以接受这样的做法:但是另外一家公司认为这不合规,不能接受.在一些公司里因为合规的

《配置管理最佳实践》——1.8 培训

1.8 培训 在选择源代码管理工具时,还要考虑供应商或者第三方机构是否有系统性的培训.有时我更倾向于那些非供应商提供的培训,因为我希望从一个没有偏见的角度去了解如何有效地使用工具,尤其是涉及工具缺陷和限制等.供应商有时认为培训只是销售过程的延伸,所以他们的培训总有种推销的味道,不能让人从公正的角度去看工具.我曾经参加过一个培训,这位讲师以前就是在供应商处工作,并且自己确实写了一些代码.他直率地讲了以前代码的一些错误,这些错误很多时候都是由于公司没有给他足够时间导致的,因为那时的首要任务是向外声称

《配置管理最佳实践》——1.2 从哪里开始

1.2 从哪里开始 实施源代码管理最好的切入点是确定源代码管理的目标和需求.我曾经工作过的一些公司,有的是集中全公司的资源来做好配置管理:而有的则是源代码管理几乎处于自我管理的状态.大多数公司开始做都是先评估其现有的做法,如确保代码安全.控制变更.建立基线和发布,包括修复补丁.当我们进行评估时,一定要确保现有的实践和进行改进的领域是依然可以工作的.采用一种平稳渐进的改进方式可以帮助避免来自团队的抵制,并且使他们在别人审视自己团队长处和短处时感觉比较舒适.我推荐敏捷和精益的做法.例如,只进行可以让

《配置管理最佳实践》——1.13 结论

1.13  结论 源代码管理是配置管理最佳实践的核心.在保护源代码的同时,利用配置管理工具和规范可提高工作效率和产品质量.在选择源代码管理工具和购买某些源代码管理功能时,一定要小心行事.培训和定义良好的使用模型有助于确保配置管理职能有效地执行且容易被接受.认真对待特殊的需求和满足这种需求时可能发生的风险.支持愿意深入了解源代码管理的人,鼓励他们分享自己的经验.源代码管理是一项团队活动.如果开发人员愿意去学习和分享配置管理最佳实践,源代码管理流程就会更加高效.

《配置管理最佳实践》——1.12 高级特性和授权高级用户

1.12 高级特性和授权高级用户 配置管理最佳实践很多专业技术人员是源代码管理工具和规范的高级用户,而另外一些人仅仅期望以最少的精力把工作做完就可以了.团队中的每个人并非都要成为一个源代码管理工具专家,但应该认可和授权那些在源代码管理方面想提高的用户.我从同事那里学到很多经验,所以鼓励你授权给那些认真对待配置管理最佳实践且愿意分享所学的专业技术人员.良好的配置管理经验是会传播的,配置管理员应该努力宣扬和弘扬这种传播.

《配置管理最佳实践》——2.5 构建工具评估和选择

2.5 构建工具评估和选择 目前有很多好的构建工具,也有很多相关的最佳实践教程.这些教程可以指导你建立一个可靠.可扩展的构建流程.这里将会讨论一些工具和最佳实践,你可以有选择性地实施其中一些来支持公司的开发工作.目前软件开发中主要有几类比较流行的构建工具.不久以前,有段时间构建自动化仅仅意味着使用 Make(也许还有一些 shell 脚本)自动执行构建过程的每一个步骤.这种方法可以很好地支持 C 和 C++ 的构建.但是在实现的时候,要注意底层不同平台带来的差异性.我在 HP-UX, Solar

《配置管理最佳实践》——2.3 构建工程的核心概念

2.3 构建工程的核心概念 成功的构建工程都包含如下职责:首先构建的依赖关系易被理解且受控,基线是可识别的,在此基础上可重复地生成构建.每次构建都是针对配置项的活动.构建包含配置项,并且可产生新的配置项.几乎构建中的任何东西都可以被认为是配置项.构建工程师的首要任务,是核实所有的可执行文件.重要的脚本.文档和文本文件已被正确地识别和标识. 2.3.1 版本ID和标记可执行文件构建工程师既能轻而易举地识别出源代码基线,也能轻松地确定构建产物的版本.这包括所有的二进制文件(中间代码和运行时模块)以及

《配置管理最佳实践》——第2章 构建工程 2.1为什么构建工程如此重要

第2章 构建工程 构建工程是高效地把源代码生成二进制文件的学科.构建工程可以很简单,例如仅仅执行一下 Makefile 或者 Ant 脚本:也可以很复杂,比如写一个完整的支持底层技术架构的构建框架.在本章中,我们将会讨论构建工程中遇到的挑战.构建工程的核心技术,以及一些选择合适构建工具的方法.我们也会讨论如何挑选和培养构建工程师.如果公司里现在没有一个合格的构建工程师,建议利用已有的资源去完成现在的工作.配置管理中构建工程是最具挑战性和最有意义的角色. 本章全面介绍了构建工程的方方面面,包括目标