·Amazon五星图书,清晰讲解配置管理软件
\r\n·透彻说明中小型开发团队中的SCM应用
\r\n·针对实际软件开发,强调相关重点和难点
\r\n·讨论常见SCM工具并解释实现本书模式过程
\r\n 有效地软件配置管理(SCM)战略促进健康的、面向协作的文化,有利于生产出更好的软件。阅读本书,可以缓解软件工程师对软件配置管理最常见的担心——觉得它僵化,过分强调过程。
\r\n 通过模式的使用,作者阐明,适当管理的工作流可以防止任务延期、士气低落和费用超支。模式法表明,SCM完全可以轻松地、成功地应用于中小型组织。理清模式之间的相互联系,读者就可以避免那些常见的令开发者灰心和令生产率降低的错误。
\r\n 本书重点讲述:
\r\n如何在解决当前软件问题的同时,开发下一版产品?
\r\n·如何和其他开发者并行地开发代码?如何跟上码线的当前状态?
\r\n·如何识别进入特定组件的是哪个版本的代码?
\r\n·如何分析在组件开发历史上什么地方有过变更?
\r\n·如何更有效地使用当前的工具?如何决定何时使用手工过程?
\r\n·如何把行之有效的实践逐步引入各工作区和整个组织?
\r\n·如何识别软件过程的关键方面,使小组的项目顺利进行?
\r\n·如何建立和培育致力于形成优秀集体和产出优质软件的开发环境?
\r\n 本书附录还详细讨论了常见的SCM工具,并逐一解释如何用它们实现本书讨论的模式。这些业已证明确有成效的技法,能帮助读者改进过程,并激发工作人员在制作更高质量软件的过程中通力协作。
\r\n
\r\n
\r\n
\r\n
\r\n
第一部分 背景\r\n 第1章 把系统作为整体\r\n 稳定性和工作进展的平衡\r\n SCM在敏捷软件开发中的作用\r\n 上下文中的SCM\r\n SCM对小组工作的支持\r\n 什么是软件配置管理\r\n 工具的作用\r\n 更大的整体\r\n 本书的讨论方式\r\n 未解决的问题\r\n 进一步的阅读材料\r\n 第2章 软件环境\r\n 总原则\r\n 软件是怎么回事\r\n 开发工作区\r\n 体系结构\r\n 组织\r\n 大局景\r\n 进一步的阅读材料\r\n 第3章 模式\r\n 模式和模式语言\r\n 软件中的模式\r\n 配置管理模式\r\n 本书中模式的结构\r\n 模式语言\r\n 语言概述\r\n 未解决的问题\r\n 进一步的阅读材料\r\n第二部分 模式\r\n 第4章 主线简化分支模型\r\n 未解决的问题\r\n 进一步的阅读材料\r\n 第5章 活动开发线\r\n 定义你的目标\r\n 未解决的问题\r\n 进一步的阅读材料\r\n 第6章 私用工作区\r\n 以隔离工作的方法控制变更\r\n 未解 决的问题\r\n 进一步的阅读材料\r\n 第7章 储存库\r\n 一站式购物\r\n 未解决的问题\r\n 进一步的阅读材料\r\n 第8章 私用系统构造通过本地构造实现全局考虑\r\n 未解决的问题\r\n 进一步的阅读材料\r\n 第9章 集成构造\r\n 进行集中式构造\r\n 未解决的问题\r\n 进一步的阅读材料\r\n 第10章 第三方码线\r\n 使用已有的工具\r\n 未解决的问题\r\n 进一步的阅读材料\r\n 第11章 任务级提交\r\n 每一项小粒度任务做一次提交\r\n 未解决的问题第12章 码线策略\r\n 制定交通规则\r\n 未解决的问题\r\n 进一步的阅读材料\r\n 第13章 冒烟测试\r\n 验证基本功能性\r\n 未解决的问题\r\n 进一步的阅读材料\r\n 第14章 单元测试\r\n 测试合同\r\n 未解决的问题\r\n 进一步的阅读材料\r\n 第15章 回归测试\r\n 对修改进行测试\r\n 进一步的阅读材料\r\n 第16章 私用版本\r\n 私用历史\r\n 第17章 版本线\r\n 发布前分支\r\n 进一步的阅读材料\r\n 第18章 版本预备线\r\n 分支而不是冻结\r\n 未解决的问题\r\n 第19章 任务分支\r\n 处理长期任务\r\n 用分支进行隔离\r\n 第20章 参 考模式\r\n 命名 稳定基\r\n 日常构造与冒烟测试\r\n 附录A SCM网上资源\r\n 附录B 工具对SCM模式的支持\r\n 参考文献\r\n
BtephenP.Berczuk自1989年以来一直从事面向对象软件应用开发,经常参加地域上分散的小组开发,从1994年首届会议起,一直是“软件模式”社区的活跃成员,很早就对组织、软件体系结构和设计模式之间的关系做过许多研究。他获得了斯坦福大学运筹学硕士学位和麻省理工学院电气工程学士学位。
软件配置管理不是我的工作。我不是软件配置管理人员。我不是搞组织工作的人。然而,我早些时候发现,作为软件开发人员,理解组织、软件体系结构和软件配置管理对做好我的工作是必不可少的。我还发现,从这个角度看待软件工程很有意义。我构造软件系统,而配置管理是构造软件系统时非常重要却常被忽视的组成部分。在本书中,我希望能说明如何避免我遇到过的一些问题,使你和你的项目组能更有效地构造系统。我大概应该解释一下,我所谓的软件配置管理(SCM)人员与构造软件系统的人员是什么意思。按照公式化形象,配置管理人员和工具与控制有关。他们保守,喜欢缓慢的、可预见的进展。与组织中占“多数”的开发者相比,他们是“少数”。软件工程师(同样按照公式化形象)则不拘小节。他们要赶快构造东西,并且自信在任何情况下都能按他们的方式编码。这些都是极端公式化的形象,而且,根据我的体验,优秀的软件工程师和优秀的版本/质量保证/配置管理人员有共同的目标:致力于交付优质系统,并尽量避免浪费精力。良好的配置管理实践不是按时构造系统的银弹,也不是模式、极限编程(Extreme Programming,XP)、统一过程(Unified Process)或你也许听说过的其他任何东西。然而,它是被大多数人由于害怕“过程”——往往是由于过去的痛苦经验(Weigers 2002)——而忽略的工具箱的组成部分。本书描述一些常见的软件配置管理实践。本书对那些在小项目组工作,觉得不能尽其所能有效地使用软件配置管理的软件开发者特别有意义。我们描述的技法(technique)与具体的工具无关。正像采用任何一组模式或最佳实践一样,能否自如地运用这些模式也许与你所使用的工具是否明确地支持它们有关。为什么我写这本书我的软件开发生涯是在波士顿地区的一个研发小组开始的。在工作中,除了遇到许多有趣的技术问题之外,还有个新的进展:与母公司所在地(纽约州Rochester市)的小组搞联合开发项目。这种体验使我刚参加工作就认识到,软件开发不仅涉及良好的设计与良好的编码实践,而且涉及同一小组,甚至不同城市的不同小组的成员之间的协调。我们组牵头设置如何共享代码及开发过程的其他人工制品的机制。我们使用通常的东西使合作比较轻松,例如开会、远程会议和电子邮件发送清单等。我们设置本地小组(和远程小组)共享代码的软件配置管理系统的方式,在使协作比较轻松方面起了很大的作用。为波士顿小组设置SCM过程的人,使用似乎一直在他们的职业生涯中屡试不爽的技法。当我转到其他组织时,我惊异地发现,有那么多地方还在为同一些常见的问题——我们早就知道有很好的解决方法的问题——而拼搏。因为我过去一直在几家刚创办不久的,我刚去时只有一两年历史的公司工作,所以情况更是如此。在新创办的公司,一两年往往是正在招募足够的人员,却很难达到协调与共识的阶段。工作几年后,我发现了模式。当时,Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides刚完成了他们的著作《Design Patterns》(Gamma等 1995),而Hillside集团正在筹备第一届PLoP会议。模式的想法有很大的力量,因为它致力于在正确的时间,用正确的方法解决问题;而且,因为模式是跨学科的:它们不是只关注具体领域或具体语言的编码技法,而是从各个角度(从编码到项目组)看待如何构造软件的问题。我在PLoP会议的各种研讨会上发表了许多论文,论述在设计、编码与配置管理交会之处的模式(Berczuk 1995,1996a,1996b;Appleton等1998;Cabrera等 1999;Berczuk和Appleton 2000)。在一次PLoP会议上,我遇到了Brad Appleton,他是比我更强的SCM专家。我们合写了一篇关于分支模式的论文(Appleton等1998),论述了SCM的一个方面。在同行们大力鼓励之下,我们开始写作本书。我希望本书能帮助你避免一些常见的错误。或者让你知道有这些途径;或者给你提供文档,使你能用来把你已经知道的途径向你们组织内的其他人进行解释。谁应该阅读本书我希望每个构造软件和使用配置管理系统的人都能从本书获益。配置管理问题的细节因你所构造的系统类型、项目组人员多少和你的工作环境而异。因为不大可能写出针对每个人的需要和使每个人感兴趣的书,所以我不得不仔细地选择我的话题。本书对那些在没有很多已定义过程的中小型组织中构造软件或管理软件项目的人最有价值。如果你在小公司、新创办的公司或大型组织中的小项目组工作,你就会从本书受益最多。即使你们组织已经有明确定义的、似乎妨碍工作进展的繁复的过程,你也可以用本书的模式更好地致力于某些关键的SCM任务。如何阅读本书 “引言”部分介绍软件配置管理的一些基本概念和软件配置管理图使用的记法。第一部分提供与SCM和模式有关的背景信息。第1章介绍本书所有的软件配置管理概念。第2章论述影响你决定使用哪一类SCM环境的一些因素。第3章介绍模式的概念、本书的模式及它们之间的联系。第二部分介绍各种模式,说明SCM面临的问题和解决常见的SCM问题的方法。第1章和第2章还定义了本书针对的总的问题。要了解模式如何互相配合,应阅读第3章,以便对模式语言有个总的认识。读过前三章以后,就可以浏览第二部分的模式,可以先阅读你认为有兴趣的模式,然后再阅读与你的问题有关的模式。也可以依次阅读各个模式,搞清它们之间的互相联系。每章的导言和章末的“未解决的问题”节可能包含对本书出现的其他模式的参考,用“活动开发线(第5章)”这样的形式表示。由于涉及领域很广,所以有些上下文和“未解决的问题”不包含对本书或其他地方的其他模式的参考,原因是在编写本书时尚未在文献上见到它们。在这种情况下,你会看到可能涉及什么模式的说明。材料来源 本书的许多材料来源于我、Brad Appleton、Ralph Cabrera和Robert Orenstein为历届PLoP会议撰写的论文。这些模式已作过很大的修改,但还是应该提到这些论文,以感谢他们为这一成果所做的贡献:《Streamed Lines:Branching Patterns for Parallel Software Development》(Appleton等1998)、《Software Reconstruction:Patterns for Reproducing the Build》(Cabrera等1999)、《Configuration Management Patterns》(Berczuk 1996b)。关于照片每章开头的照片均来自美国国会图书馆。所有的照片都是在20世纪上半叶拍摄的。只有两幅照片(第5章“活动开发线”和第8章“私用系统构造”的照片)例外,它们分别来自《大萧条时代至第二次世界大战》和《由大萧条至第二次世界大战的美国》这两组收藏品。选择这些照片的原因,是想给模式提供直观的类比。软件是抽象的概念,但我们解决的许多问题,特别是有关项目组的问题,是与现实世界的问题类似的。而且,我对照片和历史一直有浓厚的兴趣。 ——Steve Berczuk, Arlington,Massachusetts,June 2002 steve@berczuk.com http://www.berczuk.com 合作者前言为什么我和Steve合写这本书 1987年,为了付最后一年的大学学费,我作为兼职软件工具开发者,开始了软件开发生涯。不知道什么缘故,从此结下“不解之缘”,因为自那时起,我一直在做某种形式的工具开发(尤其是SCM工具),即使有时它不是我的主要工作。我甚至为商品SCM工具供应商工作过(时间不长),当时,我的部分工作是保持在竞争中的领先地位。所以,我尽可能多地搜罗市场上其他SCM工具的有关知识。即使更换工作之后,我还在继续追踪SCM,并经常在Internet上参加各种工具的兴趣小组。有一度,我渴望提高SCM环境的最高技术水平,赶上所有的最新研究成果。很快,就因为“最高技术水平”与“最高实践水平”之间的巨大鸿沟而灰心。我认定,最好是帮助提高实践水平,使现有的工具得到更好的利用。此后不久,我发现了软件模式和模式社区。显然,这些人对广为传播的、反复出现的软件设计最佳实践中,哪些是中肯的分析、哪些是无稽之谈已经有了重大的发现。当时,在设计模式社区中,几乎没有任何人尝试编写SCM模式。毕竟,对许多程序员来说,如果把软件开发比作“建筑工程”,则SCM只是其中的“管道敷设”:每个人都承认需要它,但谁也不想不由自主地涉足过深,以免难以自拔。他们只要它起作用,而不愿被迫受它更多的打扰。没有过多长时间,我就和Steve Berczuk联络上了。我们(还有Ralph Cabrera)一起写了几篇关于SCM模式的论文,作为我的ACME项目的一部分(http://acme.bradapp.net/),后来又决定写这本书。我们希望这本虽然很薄,但紧紧围绕有关集成与合作的核心模式的书,能帮助心诚的开发者兼项目领导,在成功地领导与协调项目组的通力合作及把工作成果集成为优质软件的过程中节节胜利、不断进步。感谢我妻子Maria的无限深情与支持(及我们的女儿Kaeley)。感谢我父母的鼓励。同时感谢我以前的经理Arbela的鼓励、支持与友谊。 ——Brad Appleton Arlington Heights,Illinois,June 2002 brad@bradapp.net http://www.bradapp.net