精华内容
下载资源
问答
  • 按:业务架构有三化——配置化、产品化、自动化,配置化解决业务系统灵活性、动态可变的问题,产品化解决工具复用提效的问题,自动化让机器工作、解决人力成本问题。本文来自百度刘志伟、韩炳涛两位同学对百万行配置...

    按:业务架构有三化——配置化、产品化、自动化,配置化解决业务系统灵活性、动态可变的问题,产品化解决工具复用提效的问题,自动化让机器工作、解决人力成本问题。本文来自百度刘志伟、韩炳涛两位同学对百万行配置化经验的分享,具备有一定总结的抽象性。

     

    背景

    互联网软件市场是一个快速变化的市场,优秀的服务层出不穷,所以互联网软件公司需要快速推出服务抢占市场、并且能够快速响应用户的需求,否则就面临被淘汰的命运。这跟达尔文主义的观点是一致的:

    It is not the strongest species that survive, nor the most intelligent, but the ones most responsive to change.

    大型且成熟的互联网产品为了能保持适应快速变化的市场则尤其困难,比如百度某广告系统由百万级的 C++/JAVA 代码构成,上百人工作在上面,并且每天进行着大量的业务需求迭代。由于系统演化多年,代码实现常常耦合,代码上的迭代容易引发问题,相应的回滚处理都比较复杂。静态代码构成的大型系统在编译、重型的测试上都耗费很多时间。系统不断重启升级,也影响了对外提供服务,甚至会影响收入。为了能够使复杂系统仍然能快速应对变化,我们进行了一系列服务化以及配置化的实践。

    从14年逐渐兴起的微服务架构是作为面向服务架构的一个特定方法,强调的是小而独立的服务,根本上还是对从领域里抽象成服务并进行管理。从快速应对变化的视角上看,微服务的技术异构性使得我们在面临不同的问题的时候,能够选择最适合的技术进行快速解决,以及能对服务进行组合,从而快速实现针对不同的客户提供不同的功能。除此之外,微服务在弹性、扩展性上等等都有很好的优势。此类的文章已经比较多,本文重点讲述配置化架构的实践。

    什么是配置化架构

    在软件系统中的配置通常指的是软件系统中的对象、对象属性、数据等,借助独立于软件系统的标准数据格式语言,比如xml、json、yaml,进行表达,从而能够在只改变标准数据格式语言且不改变软件系统本身功能的情况下,就能改变系统行为的方式。

    应用配置的场景非常多,比如在百度用C++开发的搜索引擎控制模块,把用户查询的关键字通过消息,发送到后端存储服务上进行检索。查询消息的超时时间,以及消息在超时后需要重新尝试的次数,都是参数类的数值。我们可以通过C++代码里直接用常量表示,也可以通过配置的方式指定。他们的不同点是,一旦数值发生变化,静态代码需要做重新编译、重启升级、往往还需要通过繁重的测试以及很多的人工操作。配置为快速变更提供了可能,不需要做编译,也可以通过动态加载的方式避免系统的重启,甚至如果变更是安全可控的,繁重的测试以及很多人工操作都可以节省。再比如开关,借助于Google 的 Gflag,我们可以在运行时灵活的控制某个功能的关闭和开启。

    架构有着非常多的定义,Roy Thomas Fielding 在 < architectural styles and the design of network-based software architectures > 把软件架构定义一种架构元素(组件、连接器、数据)的配置表示。这里配置的语义变得更宽泛了,已经不再是指单纯的标准数据格式语言(xml, json, yaml)类的配置,而是一种能够描述架构的语言。使用配置更宽泛的语义,配置化架构定义如下:

    配置化架构是指可配置的方式构建软件的方法。它是在领域建模的基础上,以配置表述业务,以配置组织架构元素(服务、组件、数据),并对配置进行规范化、自动化的管理。

    配置化架构的基础是对领域的抽象以及软件系统的高度的自动化。

    优缺点

    配置化架构的开发方式,相对于代码开发,无论是在服务的级别,还是在组件内部的级别,甚至是内部参数,都可以在不对软件功能进行变更的情况下,就能实现软件系统内的这些元素进行调整。配置化架构的优势是在较低的变更成本下,实现快速的调整软件系统。

    然而,配置的校验往往是依赖于标准数据格式(xml、json、yaml)的解释器或者额外的 schema 工具,相比于编程语言,还是缺乏更严格语义上的校验保证;而且目前往往对于配置的编辑也缺乏业务级的测试,这些都可能引入bug。所以在实现配置化架构的时候,我们需要在校验、自动化测试、以及基础设施上做很多工作;而且实现配置化架构的时候,有时候还需要借助领域特定语言,这些都引入了额外的开发、学习以及维护成本。

    平衡优缺点,建议还是从需求变更的频率的角度去考虑,在需要快速调整软件系统的情况下,实现快速以及高度自动化的配置化架构是非常有价值的。

    技术基础

    和微服务架构一样,配置化架构也不是被发明出来的,而是从复杂软件系统总结出的趋势或模式。它依赖于主要技术如下:

    • 对于领域业务进行合理的抽象和划分。为了能够进行配置化管理,业务代码必须要进行业务领域的抽象和划分,需要面向对象以及领域驱动开发的技术。

    • 为了能够对业务进行刻画,我们需要借助于领域特定语言(Domain Specific Language)。

    • 配置化架构能够进行快速调整的基础是完备的自动化基础设施。传统的周期性发布无法满足持续、快速调整的需求,借助于 DevOps 的方法论,配置化的开发做到配置的持续发布。

    架构评估

    几年以前欧洲的几个大学和几家软件公司经过多年在实践中总结,从商业、软件架构、开发流程、组织角度(BAPO)提出 FEF 软件开发的评估体系,在软件架构上,配置化成为软件架构的最高级别。配置化架构是架构努力的方向。


    实现模式

    本章是在实践配置化架构时候,针对通用问题及其方案的总结,为在实践配置化架构的时候,遇到同类的问题提供实现参考。本篇文章采用了分类的方式进行总结,「风格」指的是从领域业务模型的角度上看,用配置去实现业务的三类方式;「语言」指的是在采用何种语言去实现配置化;而「基础设施」指的是基本的配置管理、发布流程等。虽然采用了分开论述的方式,但是实际上,应用配置化架构去解决问题的时候,是综合应用「风格」、「语言」以及「基础设施」的结果。这会在案例部分展现解决问题的全貌。

    本篇文章介绍的是几类概要的实践,详细的方案以及更多的实现模式会通过后续文章持续发布。

    • 风格

      • 参数式

      • 模型式

      • 脚本式

    • 语言

      • 标准数据格式

      • 领域特定语言

      • 嵌入脚本语言

      • 配置自动生成

      • 可视化

    • 基础设施

      • 配置管理

      • 持续发布

    实现模式:风格

    配置化架构的基础之一是以配置对业务进行抽象上描述,从这个角度看,配置化架构可以归纳为三类风格,参数式、模型式以及脚本式。

    参数式

    参数式的配置是表达业务的最简单的方式,也是最常见的一种形式。比如对于功能的开关、阈值、基础组件参数值(比如消息的超时时间)等等,通常采用简单的 K-V 形式进行表达。标准数据格式语言,如 XML,JSON,YAML 等等都是支持参数式配置常用的工具。

    模型式

    模型式配置化架构解决的问题相比于参数式更为复杂,它往往需要对领域业务进行建模,才能通过配置进行表达。

    比如,当我们希望能灵活的对业务进行组合,要做到这样的事,我们首先需要对不同的业务抽象成不同的组件,分清楚哪些是业务组件要做的事,哪些是组件之间的关系。服务编排依靠内聚度与耦合度,强调服务的嵌套、松耦合性。这里说的组件拓扑指的的是将表达业务的组件和表达组件之间的关系进行分离。然后我们可以用配置表达组件的属性,以及组件拓扑,好处是能快速调整组件的属性以及关系,进而能灵活的组合不同的服务、组件完成不同的业务。

    以配置表达的拓扑关系,为了满足更多特定的业务,往往需要借助于领域特定语言,增加丰富的语义。

    以离线的数据处理为例,期望能做到特征抽取,特征合并,用户属性管理等等业务进行组合,对于不同的输入请求,需要完成的业务不同。所以这些业务代码,被抽象成组件:负责特征提取的组件、负责合并特征的组件、负责用户属性的组件等等。每个组件都有自己独立的属性配置,不同组件的以树状关系进行组合。

    在应用领域特定语言的基础上,把配置具备了更丰富的语义,能表达引用、默认值、覆盖等语义后,系统可以按照拓扑树的结构,通过反射的方式初始化内存中也是树结构的组件,每个组件会加载自己的配置。这种配置化的方式可以快速调整组件的属性,也可以快速调整组件的组合方式,达到灵活的表达业务的效果。


    脚本式

    当业务不属于参数式和模型式的时候,比如业务代码各式各样,无法用抽象的配置语言统一表达,我们可以通过脚本语言实现配置化。一般来说都是指在静态语言里嵌入了动态语言。

    以展示广告为例,UI 需要在不同的请求处理地方进行实验(实验是通过使得不同的人看到不同的展示广告,根据效果决策出更好的广告展现),然而实验的增加、变更、删除都是极其频繁的变更。静态代码在处理实验代码的时候变得很庞杂,并且也不能快速进行实验的变更。因此我们使用了 luajit ,通过 protocol buffer 和 UI 模块进行交互,完成实验的逻辑。


    实现模式:语言

    在明确了哪类风格的配置化架构后,我们需要去选择合适的配置语言去解决相应的问题。比如常见的是采用标准数据格式语言,比如 xml, json 或者 yaml 等。或者采用可视化的界面进行配置的编辑。本文介绍使用领域特定语言以及代码生成配置。

    领域特定语言

    当我们希望能以配置表达更多的需求,比如表达逻辑语义,常见的配置使用方式就无法满足了。我们需要在配置上构建更多的语义来表达业务。

    领域特定语言(DSL)是指针对某一个特定的领域,设计实现出具有受限表达性的语言。DSL 的优势在于,在特定领域下,更能直观、自然的去描述业务的方法。

    我们可以创造出新的语言表达需求。但有时候我们也会在标准 yaml、json、xml 等语法上,针对特定的需求,进行封装,使配置表达更多的业务。业界有很多这样的案例,比如 IBM 的 DB2 JSON Library 给 JSON 增加了 query 语义。

    仍然以实验为例,为了使得实验本身的信息,尤其是 condition、action 进行直观的表达、灵活的组合以及快速修改,避免了之前用 C++ 代码更新的方式。给 yaml 增加了相应的表达语义。

    4955:

        OTHER_INFOMATION: description

        CONDITIONS:

            - $ SIGN(user.domain) in TEXT_FILE('domain_blacklist.txt')

            - $ user.is_lu == 1

        ACTIONS:

            - $ pb.dcpub.noad = se_lib.NOAD_REASON.DROP_FLOW

            - $ ->FLAG_get_lu2_from_prediction_service = 1

     

    配置自动生成

    采用配置化的方式进行开发,配置规模会逐渐变得很大。我们需要确保编写与维护配置的成本要比编辑代码更简洁。虽然说配置的更新相比于代码更轻量级,然而代码相比配置,具备更好的模块化以及可重用性,使得代码在大规模的情况下仍然可以得到很好的管理。

    结合配置与代码的各自优势,我们可以把配置当成代码进行管理:以编程语言(比如 Python)生成配置,实际上配置变成方便程序识别的中间产物,RD 管理的是生成配置的代码,利用代码的模块化以及代码重用性,避免配置的维护成本更高。

    用户基于定义好的、可复用的对象以及 Python 函数,编写自己的 Python 函数,填写自己特定的配置值,完成后调用 compiler 生成配置。


    案例

    在离线任务部署的时候,每个部署任务都需要从一份配置模板生成自己特定的配置。配置的模板通过 Thrift 对象以及 Python 函数进行定义。下面是以这种方式生成一个组件的例子。


    实现模式:基础设施

    配置管理

    大部分的配置并不需要额外的管理操作,配置文件存储在 SVN/GIT 等版本管理工具上,配置内容也都不需要额外的逻辑控制,我们可以称这种简单的情况为「最简单的配置管理」。然而在配置规模变大或者需要对配置内容进行控制的时候,需要就更好的配置存储管理。

    从整体上考虑配置管理的功能时候就会发现,可以按经典的三层架构模式去理解配置管理,配置管理需要:用户交互层、业务逻辑控制层以及存储层(数据访问层)。

    「最简单的配置管理」是情况是:用户交互层提供给用户进行交互的是纯配置文件而不是通常理解上的可视化界面,并且由于不需要额外的配置内容逻辑控制,所以没有业务逻辑控制层。但它仍然是一种配置管理。当我们需要更多的功能时候,我们可以在「最简单的配置管理」上进行增加。

    这是在展示广告系统构架的三层架构配置管理,主要的内容是:

    • 提供 web UI,让用户可视化的编辑配置内容,与查看各种统计等功能。UI 到后端的逻辑控制层采用 restful API 进行交互

    • 在配置的逻辑控制层,我们对配置的内容进行基本校验、统计、存储等逻辑控制功能

    • 在后端存储,由于要复用 SVN/GIT 的版本管理功能、冲突检测合并功能、用户权限控制等功能,并且避免维护独立的Sql类存储服务器的工作量,我们采用 SVN/GIT 作为后端存储管理。


    持续发布

    配置化架构所期望的目标是能快速对软件系统做出调整。然而有时候即便是软件本身的配置能做出快速调整了,但是在传统的长周期发布方式下,除了要进行等待,对于缓存的很多变更,需要更复杂的测试以及一旦出现问题,排查以及回滚都会非常困难,这些情况都导致了不能达到快速变更系统的目的。

    持续发布是配置化架构的一个基础。配置的变更不会缓存、积压起来,而是会触发包括测试、部署的流水,进而发布到线上。即使中间有错误由于变更被拆的很小会被快速定位以及能做到快速回滚。

    这是一个在展示广告系统持续发布的示意图。从存储出发,一旦Jenkins/Hudson 检测到配置的 SVN/GIT 变化,就会触发 Jenkins/Hudson Job 流水线。目前我们的 Job 流水线主要有 2 类,首先要构建配置的 package,然后进行轻量级的自动化测试进行校验。我们甚至可以对配置进行分类,对于特定的的配置变更,比如对于不断调整的参数值,只经过基本的校验就可以直接部署到线上。


    除了百度,我们从 Facebook 的论文了解到,Facebook 可以做到每天升级 2 次代码。但是配置的升级是千次以上。他们的基础也是配置的持续发布。

    总结

    本文总结配置化架构的技术进行了概述,并且总结一些实现上的模式。更多的模式实践,以及应用配置化的案例,会发布在后续的文章中。

     


    =>更多文章请参考《中国互联网业务研发体系架构指南》

    =>更多TOP权威案例及行业标准资料请关注微信公众号:

    公众号:关注更多实时动态
    更多内容关注公众号:软件真理与光
    展开全文
  • 关于配置管理系统和配置管理项:  配置管理系统的定义是  整个项目管理系统的一个子系统。它由一系列正式的书面程序组成,用于对以下工作提供技术和管理方面的指导与监督:识别并记录产品、成果、服务或部件的...

    http://www.51testing.com/html/72/n-3723172.html

    关于配置管理系统和配置管理项:

      配置管理系统的定义是

      整个项目管理系统的一个子系统。它由一系列正式的书面程序组成,用于对以下工作提供技术和管理方面的指导与监督:识别并记录产品、成果、服务或部件的功能特征和物理特征;控制对上述特征的任何变更;记录并报告每一项变更及其实施情况;支持对产品、成果或部件的审查,以确保其符合要求。该系统包括文件和跟踪系统,并明确了为核准和控制变更所需的批准层次。

      配置管理系统的作用是

      1. 识别产品和组成部分功能和属性

      2. 控制上述特征的变更

      3. 记录每个变更实施情况

      4. 辅助审核,核实是否符合要求

      在项目中,使用包含变更控制过程的配置管理系统的目标是

      1. 建立一种先进的方法,以便规范地识别和提出对既定基准的变更,并评估变更的价值和有效性;

      2. 通过分析各项变更的影响,为持续验证和改进项目创造机会;

      3. 建立一种机制,以便项目管理团队规范地向有关干系人沟通变更的批准和否决情况。

      配置管理项

      1. 从哪里来 (谁创建,什么时候,为什么)

      2. 目前在哪里

      3. 将到哪里去

      以下是我的理解

      在PMP中,有配置管理系统,但这个系统不是我们一向认为的某个特定的软件系统之类的。是一种可以有系统管理,如果没有系统管理,人工通过文件或者架构设置工作流程都可以进行管理的系统。所以在PMP中的所有系统,都可以这样理解。(IT行业的同学,通常会理解为一个软件系统)

      配置管理系统如何理解,就要看它存在的目的。它存在的目的就是为了管理变更。所以,配置管理系统里面最重要的就是变更管理系统(这个是PMP的重点)。而配置管理系统比变更管理系统多出一部分,多出来的这部分是什么,就是配置管理系统区别于变更管理系统的部分。顾名思义,变更管理系统,只是负责管理变更,那么没有变更前,是怎样的呢,这个就是配置惯例系统负责的工作。

      举个例子:

      一个房屋装修项目,我已经确定了图纸和材料。我确定了我的窗户都是推开的窗。所以,窗户的大小,材料,和推开方式,就是某个配置项的内容。(识别产品和组成部分功能和属性)

      如果我现在要把窗户改成百页方式的,就改变了这个配置项的功能和属性。就需要提交这个变更请求,提交了变更请求,通过后,施工人员就可以看到这个配置管理项,来源是我提出的申请,在17日提出的,为了防蚊子。目前已经通过了变更审核了。将替换原来的窗户项目。

      在PMP考试中,重中之重是变更控制过程,配置管理系统是一个要点,但不算重点。因为,根据PMBOK所重点提到的,在项目管理中,用到了包含变更控制过程的配置管理系统,所以重点是变更控制。而配置管理系统属于项目管理信息系统的一部分。

      再举一个例子:

      我要购买一台电脑,肯定会考虑这台电脑需要什么配置,这里的配置,就是配置项。如果我的硬盘,要1TB,这个就是硬盘的配置项的属性。我的脑袋就是一个配置管理系统,定义了这些属性。如果听到了其他人的意见,决定修改配置,就需要通过配置管理系统里面的变更控制过程。如果还需要我老婆提供资金援助的,那么,她就是CCB了。要获得她的批准。

    展开全文
  • 软件配置管理

    千次阅读 2014-08-31 09:52:22
    恼人不休的问题:什么是软件配置管理 配置管理关注系统的集成、完整性、复用。 比喻: 保险柜:避免丢失,避免窃取或泄露; 岩钉:如果升级失败,可以回退到哪一个版本; 脚印:基线、里程碑,可以评审检查; ...

    恼人不休的问题:什么是软件配置管理

    配置管理关注系统的集成、完整性、复用。
    比喻:
    保险柜:避免丢失,避免窃取或泄露;
    岩钉:如果升级失败,可以回退到哪一个版本;
    脚印:基线、里程碑,可以评审检查;


    基本的版本控制:记录历史并防止混乱

    “因为有无数潜在的可能,会让尚未保存的修改化为乌有。比如邻桌把电源线踢了,比如编辑器崩溃了,比如操作系统崩溃了,比如一只老鼠迅速跑过键盘,后面还跟着一只猫…”
    即使只有一个开发人员,也需要软件配置管理。经常随手按ctrl+s,有经验的还会经常备份源代码。
    建立公共存储区,星形结构。
    防止版本覆盖:
    串行的方法,给文件上锁,例如早期的vss;
    并行的方法,将所有人的修改合并,例如svn、git;
    行话:
    公共存储区就是版本库。
    每次只存储不同版本间有差异的部分(增量存储)。
    每个人在自己电脑上的私有工作区。


    当代版本控制方法

    变更集:
    从源代码实际变动来看,是一个或多个文件上的一处或多处具体的代码改动的集合。
    这可能是修复一个bug,可能是小调整一个功能,也可能是一项大的工作的分解。
    通过的变更集,我们能够明确知道,某个bug是怎么修复的,某个新增加的功能,是对应了哪些文件。
    另一个重要的目标是,提供参考,便于回退。
    每个变更集对应的工作量,不要太大,所对应的源代码改动,不要太多。
    以变更集为单位修改代码并提交。
    为了保证你的工作成果能融入到当前的整个软件产品里,你需要适时更新你的工作区。
    什么时候更新:
    在变更集开始之前,可能需要更新,保证你是基于版本库里比较新的版本开始工作,不要在开始的时候就落伍。过于频繁的更新也没有必要。最后在变更集完成,即将提交的时候,最好做一次更新,并且测一下。
    源代码整体版本:
    一个程序的所有源代码作为整体,也要记录和保存版本,交给用户的是哪个版本,这个版本测试没测试过,用户报告了一个bug,是指的哪个版本上的bug。
    每个变更集提交到版本库后,自然而然地形成了产品源代码的新的整体版本。一个又一个变更集提交上来,产品向前不断演进。


    集成:关注整体质量

    注意,即便是每个改动都是正确的,也不能保证捏到一起仍然是正确的。
    集成有广义和狭义之分:
    广义:当开发人员在提交之前更新工作区,并作自测试的时候,他是在看他的改动是否能跟别人新近的改动一起工作,这是在做集成,当他做完他所在的模块的单元测试,又测了一下应用程序外在的行为的时候,他是在看他的模块是否能跟别人的模块一起工作,这也是在做集成,随后,系统测试团队对应用程序的一些版本做更加全面的测试,并把发现的bug反馈给开发人员,以便修复,这个过程当然也是在做集成。
    狭义:人们常谈论的是狭义集成,也就是集成工程师的工作,集成工程师获取源代码的最新版本,编译构建,并作粗略测试,如果此过程中遇到了问题,就解决问题,都没问题了,宣布系统新的版本,供系统测试团队深入测试,也供开发人员使用。
    广义的集成很有必要,狭义的在小规模团队不是必须的。
    提交前应该做充分的自测试,首先是单元测试,进而对系统整体进行测试。
    敏捷时代,谈到单元测试,就提到测试驱动开发:先写好自动测试脚本,再开发,直到测试通过,这样做的好处是,用简单的脚本而不是繁复的文档,在开发前明确开发的目标,而在开发后又能自动地检验该目标完成的情况。
    同行评审:又称代码走查。相关的有结对编程。
    注意:测试驱动开发和结对编程还都是存在争议的新技术。
    除了人来完成的,机器也可以在一定程度上代替人,这称作静态程序分析(Findbugs)。
    提交前,必须做了比较全面的测试,如果已经有一段时间没更新工作区了,就做一次更新,然后在工作区里编译构建,并作粗略的测试,证明程序可以运行,这种粗略的测试被称作冒烟测试。
    狭义集成的步骤:
    确保开发人员都提交了相关的源代码。
    冻结或者标示将要集成的源代码(临时禁止开发人员继续提交)。
    取出要集成的源代码。编译、链接和打安装包(如果构建过程中,遇到了问题,如果是构建环境、构建过程相关的问题,由集成工程师自己来解决,如果是源代码的问题,就由开发人员来解决。如果整个问题比较复杂,就把有问题的提交,从本次集成中剔出去)。
    安装并粗略测试。
    标示和存储集成成果。
    通知相关人员,本次集成完成。
    狭义的集成目的:生成一个基线。
    即便开发人员总是去拿公共版本里最新的内容,从统计上说,即便他们不直接使用基线,也会从狭义集成中受益。(因为狭义集成能够发现问题,不再是等到某个开发人员不幸的撞见了)
    测试人员也需要基线,对基线做全面而深入的测试,发现bug,在缺陷跟踪系统里记录下来这些bug,通知开发人员整改,开发人员修复后,集成工程师集成,产生新的基线,再次送交测试人员测试。
    广义集成三阶段:
    开发人员更新工作区、代码评审、编译链接、做一系列自测试。(因为是围绕着发生的代码改动及其周围进行,所以可以有效的发现问题)
    集成工程师狭义的集成。(在有限的时间里,保证程序在整体上没有什么大问题)
    质量保证,消灭集成过程中的问题,直到达到质量标准,集成完成。(没在第一阶段就这样全面、广泛、细致的检查,是因为没有效率)


    从源代码到运行中的程序

    构建:保证可重复性,过程尽量快,应该得到相同的结果。
    部署:当测试时,部署到测试环境,开发人员自测试也同样需要测试环境,用户会在一定的环境中安装并运行他。
    为了保证构建的结果一样,需要:
    原材料是固定和明确的。
    工具是固定和明确的。
    生成方法是固定和明确的。
    需要尽可能的文档化构建过程。更好的办法是自动化。
    全量构建:从头来过;增量构建:利用上次构建的成果。(增量的优势是快,劣势是不那么可靠)
    强调速度用增量构建,比如开发人员给自己构建的时候,而强调正确性的时候用全量构建,比如构建发给用户的版本的时候。
    让用户明确的知道所需运行环境,前提是,在产品研发过程中,明确的定义所需运行环境。


    迈向持续集成

    瀑布模型被证明是低效的。
    及早和经常的集成,这是被广泛认同的最佳实践。
    及早和经常的提交,三方面含义:
    开发人员要经常提交。(不是说没等一个变更集完成就去提交)
    如果开发需要一段时间才能提交,那么在开发过程中,要及时更新,不要留到提交前,或者干脆不更新直接就提交。
    在集成工程师这一端,要经常(狭义的)集成开发人员提交的内容。
    典型的有每日构建,在持续集成看来,可能还不够频繁。
    测试环境必须是标准的。
    不论是源代码版本控制,还是编译构建管理,还是测试运行时的管理,尽可能用简洁的方法,不要引入不必要的复杂性,因为复杂往往意味着容易出错、意味着不稳定、意味着难以重复、意味着高昂的人力成本。如果复杂性不能避免,那就尽可能的封装,这样我们才愿意有更频繁的集成,而不要在频繁的集成,在烦琐、枯燥、易错的重复性工作中耗费太多的心力。
    “集成工程师敲一行编译命令,然后喝茶 ;等编译结束,再敲一行链接命令,然后挖地雷;在集成工作结束前,他还吃了些小点心,网聊了一会儿,然后散了散步,发现相邻部门新来的女同事很迷人。但是,另一方面,他不得不工作到晚上12点,因为大部分时间,都在等待中度过了。”
    各个集成的步骤之间,最好也能够自动化。
    想要频繁而又快速的完成集成,要确定待完成的质量保证工作的内容都是必要的,测试团队也并非需要对所有的基线都做测试。
    多层集成:比如,一层是三个子任务集成为一个大任务,即增加一个新功能,而另一层是,这个大任务,与其他任务再集成。
    如何分层,以及子集成之间如何划分,基本原则:内部高聚合,外部松耦合。
    注意多层集成是有副作用:它走向了持续集成的相反方向。


    分支:减少等待,分头工作

    分支合并的目的是,把分支上的改动,合并到主干上来。主干又被称做主线、主分支、主控分支。
    当我们看整个产品的版本演进而非单个文件的版本演进时,看到的是产品所有源代码的一个断面,加上一个变更集,形成产品的下一个断面,有些断面被明确的标示,有个有意义的名字,常被称作基线,但多数断面默默无闻。
    这里的合并,是某种复制行为,分支合并并不会影响到原分支,变更集的复制也不会影响到原变更集。原分支上的变更集,以及原分支上的一个又一个整体版本,并不会随着合并而改变或消失。这里说的复制,不是指复制分支上的某个整体版本,而是复制整体版本之间的差异。
    Svn直接支持产品级分支。
    模式:通过一个位于中心的点来交换不同的开发人员或不同的开发子团队之间的代码改动,这个位于中心的点,可以是主干,也可以是分支,而位于四周的点,可以是工作区,也可是是分支。
    位于中心的点,不论是主干,还是分支,都是在服务器端的存储库里,这意味着安全,不必担心丢失,意味着每个版本都被记录下来,可以回溯,意味着在版本控制工具的支持下,不会发生版本覆盖的情况,不会混乱。
    位于四周的点,不论是用工作区,还是用分支,本质上都是达到了这样的效果:当使用它的开发人员不想受到来自外界的干扰时,他不会受到意外的打扰,也不会打扰别人。工作区或分支由开发人员完全掌控的,与外界隔离的。
    分支和工作区一样,既支持隔离,也支持共享。
    工作区与分支相比,有明显的功能上的不足,首先,记录的容量小,只能容纳一个未完成的变更集,没法记录历史,其次,安全性低。最后,狭义分支上有版本控制,能防止版本覆盖,因此可有有多人同时在上面工作,而工作区只适合单人工作。
    分支的典型应用:
    多层集成:从产品的某个整体版本开始,分支被创建出来,从这里开始生长,完成一个新功能,分支创建好了后,大家把自己的工作区定位到这条分支上,而不再从主干取最新版本。新功能开发完毕,测试没有问题后,把分支的改动合并到主干上。
    管理交迭:1.0版发布以后,在继续研发2.0版,打算基于1.0版推出1.1版。从1.0版到2.0版的开发是在主干上,而从1.0版到1.1版的开发是在一条分支上的。
    支持变体:比如推出windows版和linux版。
    隔离试探性工作:事后证明你的实现方法可行,就把这条分支合并回到主干。
    管理来自第三方的源代码:直接管理有时比较困难,可以用分支来体现。
    分支需要有意义的、符合规范的名字。在你分支命名规范中,通常会体现出对分支的分类和分组。比如,所有的用于总体集成的分支,都使用int作为前缀(或后缀)。某个叫aaa的子团队用于子集成等工作的各条分支,都已sub_aaa作为前缀(或后缀)。这样做即便猜不出具体分支的名字,但可以缩小查找范围。
    分支和分组的另一个好处是,便于划分和体现职责和权限。


    管理文档

    源代码是给机器看的,而文档是人写出来给人看的。源代码里的注释信息,本质上就是文档。如果注释比较多,就可能剥离出来,作为单独的文本文件。
    文档通常“文责自负”,通常有明确的所有者。只有他可以改动该文件,其他人如果想改动也要告诉所有者一声。通常使用工具提供的锁机制,保证不同的人串行修改同一个文档,而非鼓励大家并行修改后合并。
    文档通常“独立成篇”,文档之间相对独立。
    文档与文档之间,文档与源代码之间,经常是不一致的、不同步的。需求文档里写的需求,可能还没有转化成设计,设计文档里提到的结构,可能还没有转化成实际代码、实际功能。机械的要求他们始终一致,只会降低工作效率。
    文档被单独管理,而不是与源代码放在一起。
    可以用管理安装包一样,使用可以共享访问的文件系统来存储文档。要考虑文档目录结构的合理规划,比如用什么样的结构,叫什么名字;要考虑文档文件的合理规划,比如要有哪些文档,存放在哪个目录下,文档叫什么名字。这些规划,不仅是每个项目、每个产品的规划要合理,还应该考虑,在一个项目中积累的经验,拿到下一个项目中使用。这通常体现为目录结构的模板,其中含有各个文档的模板,以此作为下一个项目的起点。
    除了存储结构,还应该加以一定的权限管理。
    每个文档文件的命名,除了文档名称本身外,一般应加版本号,共同组成文档文件的名称。
    SharePoint
    文档本身的一些信息,比如版本信息等,要由它自身携带。
    文件名包括文档名称和版本号两部分,但这常常不够,文档中起始的一两页,常常用来更全面的记录和展现相关信息:
    关于文档的名称,在文件名中,可能是缩写,在文档黄总,就应给出名称的全名。
    应该以某种方式指出文档的“出处”,因为有时看到一份文档,会关心它有没有更新的版本,就要到文档的“官方”存储位置去找。
    文档的状态:草稿(Draft)、评审中(In Review)和已发布(Released)。
    用共享目录下的众多文件来组织和保存文档,有一些不便之处,比如对文档的并行修改,比如查看文档的修改历史记录,比如查找特定的内容就得依次打开各个文档。
    Wiki:MediaWiki
    Wiki页面中可以嵌入附件,提供搜索功能(是对内容的搜索,即全文检索)。
    通常企业内部信息比较适合用wiki来承载。
    有的文档用章节的形式组织,用文件来承载,不一定总是最方便的。比如一些需求管理工具、系统建模工具等。


    跟踪缺陷,直到消灭

    Bug的跟踪系统,学名叫缺陷跟踪系统,bug的学名叫缺陷(Defect)。
    有些团队使用excel表格来处理缺陷跟踪。
    BugFree
    缺陷的状态:
    已报告(Reported),又称创建、打开、初始,一般谁发现谁来填。
    已分配(Assigned),分配给开发人员,条目里填上开发人员的名字。
    已解决(Resolved),开发人员解决了这个缺陷。
    已关闭(Closed),由测试人员完成,确定这个缺陷真的被修复了。
    已报告的缺陷也会被认为不是真正的缺陷,会被直接关闭(加上些注释最好)。
    重复的缺陷条目,也把它关闭(注释它跟某个缺陷是重复的)。
    已解决的缺陷,测试人员发现它并未真正的解决,通常会重现打开,分配给上次修复它的开发人员(变回成已分配)。
    本质上,我们是在讲述有限状态机在缺陷管理中的应用。
    每条缺陷记录有一行标题(Title)或者叫总结(Summary),用来简述缺陷的内容。
    一些字段起到类似作用,比如关键字(Key Words)。
    详细描述(Description)一定要做到令开发人员和测试人员可以复现这个缺陷,要详细记录当时的操作环境、当时的操作步骤,以及当时的缺陷现象,这是处理缺陷和检验处理结果的依据。
    严重程度(Severity),轻微、一般、严重、致命。
    优先级(Priority),低度、中度、高度、最高。
    规模小的团队,通常不必要优先级。
    要遵循一个原则:避免带着许多缺陷前进,要尽快消灭。
    对缺陷的统计:
    回答缺陷是怎么分布的、数量是多少。柱状图、饼图等。
    回答随着时间的迁移,缺陷的总体趋势是什么样的。趋势图。
    关于缺陷的年龄的统计,时长图。
    这些数据的采集和展现,应该尽可能得到缺陷跟踪工具的支持,人工来做,耗时费力。
    通常可以把一条缺陷记录和一个变更集关联起来。便于查看这个缺陷的修复究竟改动了哪些源文件。简单的方法是,在变更集的标题或描述中,记录相应缺陷条目的编号。注意,缺陷记录和变更集之间的关系,并不一定总是一对一的关系。


    管理变更

    请求修复缺陷只是变更请求中的一种。
    增强:指一些小的请求,把程序已有功能稍稍增强一点。注意,增强所导致的修改,常常不仅是源代码的修改,可能需求文档因此修改,用户手册也要修改,测试用例也可能要修改。
    特性:典型的Scrum(一种以迭代、增量为主要特点的软件开发过程,是敏捷开发的一种),所有待完成的特性都列在产品订单里,每次迭代前,从这里挑出来本次迭代要实现的条目,把这些条目列在冲刺订单里,每次迭代通常是15到30天。在迭代过程中,一般不会改变冲刺订单,再一次迭代完成后,回顾工作成果和经验,再计划下一次迭代。类似的另一个典型是特性驱动开发(FDD)。
    缺陷、增强、特性,从配置管理的视角来看,它们都是变更请求。
    瀑布模型中,变更管理很中哟啊,一旦定下来的事,就要执行,不能乱改。但也不能禁止变更的发生。核心是严格控制变更。常见做法是设立变革控制委员会(CCB)。
    因为变更控制的流程本身也耗费很大,所以使得团队越来越倾向于迭代的、增量的开发方式。让每次迭代需要开发的内容较少、容易确定;在设计和实现时,及早发现问题,在功能实现后,及早获得用户的反馈。项目早期的迭代,会把比较多的注意力,放在典型的、最重要的需求上,会把注意力放在产品的整体架构上,然后,通过编写代码以验证关键设计,通过向用户展示可运行的程序以验证关键需求,尽早的到这些关键问题的反馈。这样,以后的风险和难度就小多了。
    缺陷一般来说都会被修复,而功能增强、新功能增加这类的变更则不同,即便是正确有效的,也很可能因时间、成本等因素不去实施,需要评估:
    变更的大小、变更的影响面、变更的风险、变更发生时间、研发规模。
    在版本控制工具里,可以考虑加一些控制,以保证开发人员做且只做该做的事,一种方法是,让变更集不由开发人员创建,而是由管理人员创建,然后指定给相应的开发人员完成。另一种方法是修改代码之后提交时控制。大多数情况下不需要这样的控制,除非是临近项目结束等,以保证集中精力在最重要的事情上。
    需要以一定的方式表达产品版本间的差异:
    查看版本控制工具。
    查看问题跟踪工具中的变更请求。
    查看项目计划或迭代计划。
    查看需求数据库或需求文档。
    集成工程师可以考虑使用脚本,在每次集成后产生完成条目的列表。


    玄妙的学院派

    当你打算开始软件配置管理工作时,先弄清楚要管哪些东西,包括:源代码、文档、安装包、环境和工具、编译工具等,这并不意味着一定得一个文件一个文件的标,源代码通常作为整体标出来就可以了,怎么划分全看如何让工作方便,在术语上,我们管这样标示出来的每一项的特定版本叫配置项(CI)。
    配置控制(Configuration Control),特别是对变更请求的管理。
    对于变更,协调工作:
    考虑不同的变更请求之间的关联性,有些变更可能是说的一回事儿,或是相关的事,需要统筹考虑它们对设计的影响,它们的实现成本,是考虑让他们一起实现,还是拒绝或拒绝一部分。
    一个变更请求可能会影响到不同的产品,可能对他的改动是在一个公共组件上的。
    协调先后顺序,有的比较急,有的比较大,有限安排人力资源去完成,有的则可以拖一拖。
    配置状态报告(Configuration Status Report),做配置管理,需要数据和信息的支持,包括三类典型的信息:(以车辆设计为例):
    车辆由哪些零件,什么型号的零件组成的。应该是一个列表。
    车辆设计在正式批量生产前,可能有改动的请求。变更请求的状态应该被记录。
    变更实现的情况。
    这些信息和数据,表现形式有三种:查询结果、报告和图表。
    配置审计(Configuration Audit),是指对象本身是否符合需求或相关的标准,而不是制作对象的过程。
    首先,要确保需求文档反映了客户的需求,设计文档反映了需求文档的要求,源代码实现了设计文档的目标,这样一层层递进,以确保跑起来的程序,就是客户想要的,这些主要是通过评审来实现的,特别是在瀑布模型中。在确定需求的时候,要与客户一起讨论、评审,直到需求文档被一致认可。在确定设计的时候,要与相关人员一起讨论、评审,直到确定设计文档的内容能够实现需求文档的要求,并且能够编程序实现它。在源代码编写完毕,要做同行评审,看是否符合设计,是否实现了需求,是否正确无误。
    上述审计,大都需要评审者具有软件所在具体领域的知识,对软件的具体功能进行检查,这叫做功能审计。
    在发布给客户的内容,是一个安装程序、一个发布说明文件和一个使用说明文档,那么在打包发布前进行检查,看这三项是不是都有,就属于物理审计。
    能力成熟度集中模型(CMMI)中,对配置管理工作,从如下角度进行了划分:
    建立基线,首先识别配置项,接着建立配置管理系统,用来存放配置项,最后通过评审或测试后,由配置项组成基线,作为未来开发的基础。
    建立并控制变更,要追踪变更请求,要评估他们,分配给合适的人去处理它们,还要检查以确保它们确实被处理了,要控制对配置项的变更,如果要改它,需要合适的人同意,改好后,要适当检查,才能入库。
    建立完整性,首先要对配置管理活动做足够的记录。其次要进行配置审计,确定配置项的内容是否合适,并出现在合适的地方,确定基线的内容正确。
    制度化已管理过程,在一个软件研发项目中做配置管理,首先要建立配置管理计划,然后确保有足够的资源,包括工具、环境、也包括人员,在配置管理系统运转过程中要适当监控。
    制度化已定义过程,要形成可以指导现在和未来多个软件研发项目的配置管理过程规范,这样的规范不是一成不变的,要收集相关信息、数据和反馈,并基于此进行软件配置管理的持续改进。
    软件能力成熟度模型(SW-CMM)已被CMMI取代。
    这些软件研发模型和标准都有光辉的思想在里面,都是有价值的东西,然而,是充分发挥出价值,还是没有产生价值,甚至产生负面影响,要看怎么去用它们,基本的原则是,深刻领会标准的内在思想,结合企业的实际情况应用这些思想,而应用标准需要有所选择和裁剪,对于特定研发背景,要弱化甚至舍弃不适用的部分,要以合适的方式具体化和实现需要的部分,应用标准来不得教条,不要为标准而标准,更来不得表面文章。


    用分支实现迭代

    先考查一下如下的情形:主干上比较古老的部分,是目标为1.0版的研发,主干上某一点,是1.0版本发布了,随后,主干上开始目标为2.0版的研发,现在正在向前演进,为支持1.1版,我们从主干上1.0版本发布对应的那一点起,做一个分支,岔出来,这条分支的目标是1.1版,也可能将来1.2版也在这上面。
    把1.1版称作补丁版本(Patch Release)。
    没有采用完全独立的两个目录或两个版本来实现,是因为,分支除了有隔离的功能外,还对共享有比较好的支持,使用分支,便于彼此同步和复用。
    理想情况是,在1.x分支上,从1.0版起到1.1版之间所有的代码改动都应该拿到主干上,贡献给2.0版。
    比较保险的做法是,对1.x分支上的每一个变更集,均由开发人员做出判断,是否适合合并到主干。
    一般来说,新的分支在刚创建的时候问题不多,因为两个分支上的内容差不多,随着时间流逝,两个分支上的内容相差越来越多,这时候把一个变更集从一个分支复制到另一个分支,就会越困难,出现各种问题的可能性就越大,可能需要因此而调整合并的策略,引入更多的检查。
    关于不同分支间合并,还要注意合并的频率,定期合并也不错,只要两次合并的间隔不要太久。
    这里谈到的分支,可以是广义上的分支的不同具体形式,可以是狭义的分支,也可以是分布式版本控制工具中的不同的版本库,或者其他的方法。只要这些方法能够方便的做到不同(广义)分支之间的隔离和共享就可以。
    甚至早在1.0版发布之前,就启动2.0版的开发,可以借助分支。
    从老板开始决定开始,创建一个新分支1.x,在这条分支上开发,直到没有问题了,1.0版在这个分支上发布。
    而在主干上,从那个位置开始研发2.0版对应的新功能了,这跟分支上1.0版的开发相互隔离,不会彼此干扰,另一方面,分支上的工作,包括少量新功能和大量的缺陷修复工作,对于2.0版的开发同样有用,所以,分支上提交的绝大部分的变更集,应该被复制到主干,这跟补丁版本的开发是差不多的道理。
    应该在什么时候创建1.x分支呢?当开发人员要提交第一个仅针对2.0版而不适用于1.0版的变更集的时候,这时主干的断面可以作为1.x分支的起始版本。
    在产生了1.0版本之后再创建1.x分支,被称作并行发布(Parallel Releases)。
    当项目的里程碑有0.5版、0.8版,这两个重要的内部版本,为了能通过里程碑而进行的缺陷修复工作能并行起来,可以借助分支。
    当集成时,预计需要比较长的时间时,可以考虑让集成一问题解决工作于开发人员的继续开发和提交并行起来,也可以借助分支。
    如果每当集成遇到问题的时候,我们就开出分支,这样分支就会有点多,有改善的办法:用一条长期生长的分支而非很多个短分支来支持集成过程中的修改。并且,总是在该分支上发布新的基线,由于这个原因,该分支常被称作发布分支。
    具体来说,开发人员提交代码改动到主干,每次集成时,集成工程师把主干上的最新内容合并或干脆复制到发布分支,在发布分支上制作正式的基线,供开发人员和测试人员在必要时使用,甚至发布给外部用户。
    可以看出,在集成的过程中,主干一直是开放给开发人员的,随时提交任何修改,与本次集成互不干扰,这和使用多条短分支来支持集成的效果是一样的,却能避免频繁的开分支。
    使用一个长分支代替多个短分支,可以多次集成不会打架。
    这种一个分支和主干上期并行并且上面的内容彼此很接近的分支结构,称作双分支结构。
    适用于以下的场景为例:
    当软件研发团队,研发的某款软件,部署到服务器上,专供A公司使用,在某一时间只会使用软件的一个发布版本,而非多个,并且,软件发布通常是循序渐进的,每次增加一点新功能。这时可以使用双分支,当服务器上的程序暴露出比较严重的缺陷时,或因为A公司的业务调整需要紧急调整某个功能的算法时,需要紧急开发和发布一个补丁版本,这时,补丁版本的开发可以在发布分支上直接完成,并在发布分支上产生基线,向A公司内部发布,并部署到服务器,此后,把发布分支上为此次补丁版本所作的修改合并回主分支。
    交迭(Overlap),本质上,前面说的都是分支,用分支来支持交迭,一条分支上,重点是质量,重点是稳定性,另一条分支上,是要增加新功能,是要全力发展,两条分支,既防止了后者干扰前者,也防止了前者阻滞后者。


    用分支实现变体

    变体(Variant),又译为变种,指一些软件产品,它们彼此有一些相同之处,但又彼此有所区别,就像一群兄弟姐妹,弟弟将来无论怎么长,也不会长成和哥哥现在的样子一模一样,比如一个软件的windows版和Linux版。
    产生变体的原因:
    因支持不同操作系统而产生变体。
    因不同的功能集而产生变体。
    因客户定制而产生变体。
    可以用分支来支持变体,主干上的改动不断的同步到1.0-A分支上。当推出2.0版时,为了开发2.0-A版,有两种方法:把主干1.0版到2.0版的所有修改都复制到分支上,这时的分支应该叫A,以后的1.0-A版,2.0-A版等等;还一方法是,在2.0版或者2.0版之前的某个位置,创建一个新分支2.0-A,把分支1.0-A上为变体特殊需求所作的修改所对应的变更集都复制到2.0-A上。方法二优点是对分支合并引入的代码修改进行浏览和审查比较容易,缺点是如果会频繁的推出发布版本,分支就会创建很多。
    使用分支来支持交迭,代码改动在分支间的主要流动方向是,从两边向中间流动,从分支流向主干。而当用分支支持变体时,代码改动在分支间的主要流动方向是,从中间向两边流动,从主干流向分支。这是分支支持交迭和变体时的重要区别。


    用设置实现变体

    在版本控制工具看起来是相同的源代码,构建工具却可以选取其中不同的部分来构建,于是就会产生不同的程序,互为变体。
    很多应用程序在运行时从配置文件中读取设置信息,在windows操作系统中,可以把设置信息放到注册表里,这些信息也可能是加密的。
    运行时的程序还可以通过探测运行环境,而改变自己的外在行为,比如一款手机,但它运行在某个运营商的网络中的时候,它显示出该运营商所要求的一些功能。
    在安装和运行时读取设置信息,与构建时读取设置信息相比,最大的好处是减少了构建的数量。
    在运行时读取设置信息,可能会影响到程序运行的性能。
    构建时、安装时或运行时读取设置信息,实现变体。这类方法与用分支的方法相比,其好处主要是,不需要做代码合并工作。对于公共代码,在工作区中一次性的完成工作,即对所有变体都产生了效果。
    从程序的外观和行为,从程序使用者的角度,讨论是不是变体,就好像是讨论究竟有多少头发算秃顶,多少根头发不算秃顶。
    而从软件开发的角度,问题的关键不是什么才算变体,而是具体通过什么手段,来实现程序外观和功能的不同。
    一般原则:尽可能晚的实现变体,这样做,开发成本比较小。


    用组件的组合实现变体

    在平台加应用的模式里,程序是若干模块的组合,其中有一个特别大,被称作平台,其他的模块,被称作应用。同样的,一个软件的变体,可以由不同的组件组成。
    系统由组件组装而成,组装可以发生在软件从源代码到运行中的程序这一生成转化过程中的不同阶段。
    我们从源代码的组装谈起。源文件在一起构成目录,目录在一起构成更大的目录,以此类推,直到系统整体。或者从软件结构上说,文件构成模块,模块构成组件,组件构成子系统,子系统构成整个系统。
    对于大型系统,其所对应的源代码量很大,开发人员又很多,如果用一个版本库,一些版本控制工具的性能会成问题。如果出现了这样的趋势,解决方法之一,把源代码分成不同组件,放到多个版本库中。
    即便是系统的不同的变体都使用了某个源代码组件,使用的内容也可以是不同的。也就是说,该源代码组件的不同版本,参与了系统的不同的变体的构成。
    需要强调,这里所谈论的源代码组件,是从软件配置管理角度所划分的组件,划分关键是,一个组件是考虑软件复用时方便软件配置管理特别是版本控制的最小单位,如果从软件架构角度所说的若干个模块来看,它们永远是在一起,并且把它们作为整体来开分支、做基线就可以管理得很好,那就把它们当做一个源代码组件,而不是硬要分成多个组件。典型的例子是,在平台加应用这个模式中,平台尽管很大,但经常可以当作一个组件。
    基线,狭义的说是集成的成果,具备一定质量的整体版本。当系统由组件组成的时候,系统的基线由各个组件的版本,常常是各个组件的基线组成的。因此我们把系统整体的基线称作复合基线(Composite Baseline)。
    系统整体版本特别是复合基线的概念,并不总是那么重要,当系统的各个组成部分比较独立,当用户自己能够选择和更新各个组件时,整体版本的概念就不那么重要了。比如Android或者iPhone手机,用户关心的是手机操作系统的版本和各个应用程序的版本,而非它们的整体版本。
    实现软件复用的需要:
    一个适合复用的软件系统架构,组件内部,高度聚合,组件向外提供明确清晰的接口,组件之间,通过接口,相互配合。这里所说的组件,可不是一个类或者一个函数级别上的,一个系统,可能有成千上万个函数和类,这里说的组件,是粒度比较大的组件,可能是若干基础函数和类的集合、一个工具箱,供应给程序使用。使用面向对象语言编程,有利于实现组件化及组件复用,但这既不充分也不必要,面向对象设计和面向对象分析更为重要。
    一个适合复用的研发过程,以产品为中心的软件研发过程,是不适合复用的,这样的软件研发过程,会集中精力于一个又一个产品本身,很难顾及到公共的部分,顾及到资产的复用。在研发过程中,要保持公共组件的常用版本的公共性。
    一个适合复用的人员组织结构,在研发过程中,考虑对系统标准版本,以及对公共组件的常用版本的研发、单独立项,保证其具有一定的独立性,保证有足够的资源供应,这里的资源供应,主要指的是人力资源,应该有单独的项目组,来开发公共组件的常用版本。对于每个具体的应用软件系统,也应该单独立项,而在两者之间,应该有人进行总体规划工作和随后的协调工作。


    支持多地点开发

    对于跨过企业,可以利用时差,由不同国家的员工轮班倒着干。
    不同地点开发,形成了某种隔阂,比如沟通问题,会倾向于自成体系,可能使得不同地点开发的内容接口不一致,无法集成在一起,也可能使得不同地点开发的内容,外观风格不一致,看起来像两个产品拼凑而成。除此之外,还有时差,不同文化。
    如果一定要采取多地点开发,可以让每一个地点的团队或个人,负责相对独立的一块源代码或完成相对独立的工作任务。比如,以组件为单位,把不同的组件,分配给地理上不同地点的团队开发,而组件间的接口要清晰简单,并且应该尽早讨论、确定并记录,这样,有助于减少对不同地点间人员沟通的需求,也减少对环境和工具的要求与依赖。再次,要加强协调和配合,要有适当的人员进行总体的管理,进行各站点之间的沟通和协调,要有合适的流程保证各站点之间的同步。


    从开源到外包

    从获取资产的来源上分,除了开放源代码和免费产品这类外,还有其他厂商大量出售的标准软件,比如操作系统,一种是其他厂商专门生产的软件,常被称作外包。这些资产,称作第三方资产。
    对第三方资产的管理,首先要适当的标示和记录他们。其次要存放好这些资产,并能方便的访问和使用。最后要管理外来资产的版本变更。
    最好在本地存一份源代码,具体的说,就是导入到本公司的版本库里。
    Svn自带一个脚本,可以方便的不断导入第三方源代码的新的版本。


    管理软件部署

    不论是对内还是对外,各类安装包应该有相对统一的存放地点。简单方法是使用一个共享目录,并设置了合适的读写权限。不仅要存储安装包的最新版本,还要适当存储历史上的版本。因为有时要退回到历史版本上,要把历史上的版本与最新版本进行比较。
    安装也需要做计划,何时安装、安装哪些内容、怎么安装、有什么前提条件。应该考虑到如果安装出现问题,能否回退到安装前的状态,如何回退。应该考虑到先做一些实验性安装,没问题再正式安装。安装应该得到适当的批准,在具体安装前,应该仔细进行检查,检查版本、检查运行环境、检查相关关系的呢过。在安装时,要严格按照预定的步骤安装,并观察是否有异样。要记录整个安装的情况,以便将来回顾。在安装后,应该做一些粗略测试,以验证安装成功。
    就像研发过程中的配置管理异样,对线上运行也需要把这些配置识别出来。除了当时的配置信息外,历史上的配置信息也同样需要考虑记录。
    在系统运行过程中,可能会有来自各方面的变更请求,这些变更请求的一部分就是对软件研发的变更请求,但是,并非所有这些请求,都需要送到软件研发部门,有些变更请求,是对当前运行系统配置的变更请求,也就是说,是对运行哪些系统,包含哪些组件,使用哪些服务器等方面的变更请求,也包括对运行系统的一些设置、使用的一些数据的变更请求。这些请求,就像软件研发的变更请求一样,需要记录并跟踪,以防丢失。需要分析评估,考查它的成本,它的风险,它所带来的收益。在实施变更的前后,要通知相关受影响的人。
    网站开发和管理的困难在于,有时候不好分辨,哪些算是软件研发的输出,哪些算是运行时的配置和设置,哪些算是系统运行行为本身。因为不好分辨,所以更要明确责任。要明确,哪些内容由谁来负责,如何修改。而它的前提是,网站有比较好的系统架构,并且有比较好的工具支持,能够把脚本程序的变化、页面编辑产生的变化和运行时的变化,三者分离开来。因此,网站要有比较好的系统架构,并且有比较好的工具支持,其中的工具主要是指网站内容管理系统(CMS)。


    软件配置管理实施

    不同阶段,不同挑战:
    第一阶段,一个软件开发组织初创之时,这时候的当务之急是,建立起软件配置管理的基本解决方案,其中最重要的是,引入源代码版本控制工具,把源代码管理好,防止源代码丢失、版本覆盖、版本混乱等各种问题,有了源代码版本控制工具,开发就可以比较顺利的进行了,随后的要紧事,是建立起基本的缺陷跟踪系统,其主要目的是让测试团队和开发团队能够有效的合作。
    第二阶段,软件开发团队的规模不断增长之时,这通常伴随着源代码量的迅速增加,编译构建所需时间的不断延长等,这一系列的变化给集成(广义和狭义)带来了越来越大的压力,在这个阶段,我们的关注重点是围绕着集成的优化,比如,如何在狭义集成前、集成中、集成后合理的分配质量保证工作?如果让构建更快?如何让测试更快?能不能让狭义集成过程完全自动化?如何实现持续集成?等等。
    第三阶段,发布多个版本、多个项目、多个产品之时,此时的主要挑战是软件配置管理对软件复用的支持。实现软件复用有多种模式、多种方法。注意选取适当的模式,并注意不同模式同时使用时,如何相互配合。这些模式中,以组件的组合对软件配置管理的挑战最大。另一方面,当版本、项目、产品的数量很多时,数量本身也带来挑战。比如说,三五年前的某个项目,你知道它的源代码就在公司的某个版本库的某个目录下,但是到底是哪个版本库哪个目录呢?
    以上三个阶段的划分,只是常见、典型的情况。并且阶段与阶段之间,也并没有非黑即白的明确的界限。请以此为参考,根据你所在的研发组织的实际情况,确定当前的工作重点。


    如何完成一项改进

    不论是引入一个版本控制工具,还是改变提交源代码修改的步骤,抑或是调整关于内部版本命名的规则,在本质上,都是对现有的软件配置管理解决方案进行一项改进。这一项改进可能是关于软件配置管理工具的,或软件配置管理相关流程的,或两者都有。不论完成一项什么样的改进,都有一些通用的步骤和要点。
    在改进方案调研和选型时,要对所在研发组织的实际需求有真切的了解。比如,现在需待解决的问题是什么,对某项指标有多高的需求。举例来说,某个工具号称能支持2000人同时使用,而你所在的研发组织,现在只有20人,未来三年的目标是发展到100人,那么这个工具的这个高指标对你所在的研发组织并无意义。工具软件厂商和服务咨询的提供方可能会夸大你的需求,暗示你有某方面的需求,以此来引诱你花大价钱购买其实你并不真正需要的工具或服务。
    用免费的工具还是收费的工具?传统上认为,收费工具通常质量更好,出了问题能得到及时的修复,关于工具如何使用,也有工具厂商能够提供专业的解答。然而,相应的开源免费工具,如果足够流行,被成千上万的软件研发组织使用,那么它的质量通常已经相当好。并且,有些新兴的开源工具与一些有年头的收费工具相比,明显具有更好的架构,因此有更好的性能,也更容易维护和使用。在今天,开源免费的工具,有可能是一个更适合你所在的研发组织的选择。
    某个改进,特别是流程上的改进,在研发组织作为整体因此而受益的同时,可能也有一些部门、一些团队、一些个人没有因此得到好处,甚至受到损害,比如工作步骤变得比以前繁琐。他们可能会成为变革的阻力。如何解决?方法之一是,识别出这个改进的主要受益方,与相对应的管理者沟通,请求他的帮助。他经常有很大的热情,从管理者的角度去协调和推动这项变革发生。
    从改进方案的讨论阶段开始,就要注意保持与利益相关方(Stakeholders)的沟通。确定改进方案确实是他们想要的,尽量满足不同方面的需求。在确定方案后,如果实施改进所需的时间较长,那么应该适时汇报阶段性的成果。
    尽可能把你心中的宏图伟业,落实为一个个小的改进项目或阶段。每一个都有明确的产出,对研发组织有实质性的贡献。小的改进与大的改进相比,风险更小、实现较快、可根据反馈及时调整,比较容易得到批准、付诸实施。并且,通过一个个成功的改进,不断累积你的信用,日后打算进行一些革命性的改变时,会更容易获得支持。
    一项改进本身的质量保证工作该怎么做?除了改进需求评审、方案设计评审、代码评审、在测试环境测试等方法外,试点(Pilot)也是一种=广泛使用的方法。试点是在真实的环境中小范围的试用新的方法。这样,出了问题负面影响也不至于很大。同时,由于是在真实的环境中试用,如果没什么问题,那么就可以比较放心的推广。
    要成功实施一项改进,培训、支持、文档也很重要。通过培训等方法,让具体的使用者充分了解为什么要改变,改变到具体什么样的流程和操作方法。当使用者遇到问题时,要提供方便的途径,让他们的问题得到解答或解决。培训和支持都是向使用者提供的服务。如果能够让使用者在很多时候自己帮助自己,那就更好了。如何做到呢?如果有合适的相关文档,文档具有合适的结构和合适的内容,易于使用者阅读、便于使用者查找,那么就能够在相当程度上减少支持使用者所需的人力。


    在一个项目的生命周期中

    制定计划:凡事预则立,不预则废。制定计划,意味着考虑在这个产品的开发过程中,软件配置管理要怎么做,这包括软件配置管理的方方面面。
    通常上会遵循和使用该企业已有的软件配置管理解决方案,但需要仔细研究具体项目的特殊之处,比如多久一次导入、如何送回公共改动等一系列问题,还有团队是否分布在不同的地理位置,不同的产品之间是否存在复用,等等,这些是这个项目中的软件配置管理的特定场景(Scenario)。
    对项目的软件配置管理进行计划,并不意味着一定要写一份名叫软件配置管理计划(SCM Plan)的厚厚的文档。作为计划的成果,有些内容可能写在了某个wiki页里,另一些内容填在某个表格里,甚至有些内容干脆就是写在一封电子邮件里告诉大家。
    做好准备
    要做哪些准备工作,深受组织级软件配置管理工作的影响。
    如果公司已经提供了可用、适用的软件配置管理工具,如版本控制工具等,则只需简单的为这个产品进行初始化工作。比如,在其中创建项目、创建目录、导入初始版本、设置合适的参数,等等。如果组织级并未提供合适的工具,则需考虑工具的选择、购买、安装、设置等一系列事宜。
    如果公司已经确立了通用的软件配置管理过程,则应该考虑拿来使用。这可能是全盘接受,也可能是在此基础上,根据项目的实际情况,如开发团队规模等因素,进行适当的裁剪和定制。而如果当前项目情况非常特殊,则可能需要部分或全部的为项目特别制定软件配置管理过程。当组织级没有确立或没有完全确立通用的软件配置管理过程时,也会有这样的情况。一般来说,在做软件配置管理计划时,应该同时完成过程方面的准备,或者已经完成对这方面的重要决定。
    而在人这一方面,要保证各个软件配置管理相关岗位,已经有合适的人选,并具备了在该项目中完成配置管理方面的工作的能力。他们应该有足够多的经验和能力,如果欠缺,应该考虑进行相关培训。
    日常工作
    软件配置管理系统日常工作,牵扯到项目团队所有成员,因为所有成员都需要与软件资产打交道,也就需要与软件配置管理打交道。从这个角度讲,不同的角色,所有的团队成员,都是软件配置管理系统的一部分。
    而软件配置管理工程司主要的职责是保证软件配置管理系统的正常运行。比如,当工具需要某些维护工作和手动备份工作时,需要做一些相应的工具方面的维护和备份工作:当人员有增减的时候,需要开通和管理相关权限;当使用者遇到的各种麻烦需要解决时,需要回答工具和流程方面的疑难问题,这被称为Trouble Shooting。另外,还需要为一些软件配置管理的具体事宜、具体案例给出意见或作出决定,比如,具体的某个开发任务,是开分支来支持比较好,还是只使用主干来接受相关变更集的提交好。
    当然,在一些研发组织中,软件配置管理工程师同时兼任集成工程师,也承担集成工程师的职责。
    监控、调整与改进
    软件配置管理系统的运行,既需要参与者的深刻理解和自觉执行,也需要某种形式的监控。这首先是因为,每个团队成员都有其关注的焦点,比如开发人员集中精力与编写代码,测试人员集中精力于发现程序中的问题,项目经理集中精力于项目的按时完工,并让客户满意。而遵循软件配置管理规定,并不是他们关注的焦点。其次还因为,每个人都有失误的时候,都有犯错的时候,如果这些不被及时指出和纠正,就会被效仿。而监控的目的就在于,及时发现问题,及时发现没有遵守纪律的问题,并敦促改正。
    但是,即使团队成员严格遵守项目中软件配置管理的各项规定,让软件配置管理系统严格按照规定运行,也仍然有可能出问题。因为,随着项目的演进,项目所在的环境,项目对软件配置管理的要求,都在不断变化。比如,变更请求管理越是到项目后期越是严格。因此,项目的软件配置管理策略、方法,需要随着项目的进展进行调整。这是第一类调整。
    而有些调整是因为另外的原因,是因为在定制计划时,不能准确的估计到项目对软件配置管理的需求:不能准确的估计到在这个项目中,各项软件配置管理工作应该怎么做,应该做到什么程度。比如,在项目之初,可能认为在这个项目中为试探性的工作开分支没有必要的,因为预计没有比较大的试探性工作。但是项目实际运行中,确实遇到了比较大的试探性工作。这时候就需要进行调整。这是第二类调整。
    随着对软件配置管理的认识不断提高,会对流程进行调整:随着新的软件配置管理工具的选型、购买、安装设置的完成,会对项目所用工具进行调整。这类以提升为主要特征的调整,通常被称为改进。改进往往具有组织级的意义,最终是在全公司实施。
    收尾
    在产品发布、项目收尾阶段,软件配置管理同样需要进行收尾工作。这主要包括两个方面,软件资产的整理和归档工作、软件配置管理本身的总结和共享工作。
    软件资产的保护,在项目收尾时进入关键时刻。这个时候保存的软件资产,是已成型的软件资产,是最有价值的资产。同时,这个时候的软件资产,是上市软件产品对应的软件资产。这个断面,在将来很有可能被用来作为维护和继续开发的基础。而另一方面,这个时候的软件资产,如果不及时进行整理和归档工作,又容易被渐渐遗忘,最终丢失。随着硬件设施的迁移,随着其他的变迁,先是很难找到它到哪里去了,进而被从物理介质上清除,再也无从恢复。
    软件资产的整理和归档,包括对源代码、对安装包、对文档的妥善保存;包括对各个历史版本,特别是发布产品对应的历史版本的妥善保存。这可能通过某种备份来完成;也可能是转移存储地点,从活跃的经常被存取的存储地点,转移到不活跃但更为安全的存储地点。
    而对构建方法的整理和归档,对于环境的整理和归档,也同样重要。否则,在将来,有可能即使复现了当时的源代码,却不能生成对应的安装包;于是源代码资产也失去了价值。
    对变更请求等相关数据也应该进行整理和归档,保证将来仍可查阅。
    这些是对软件资产的整理和归档工作,而对软件配置管理本身,同样存在着整理总结的工作。因为,软件配置管理本身也是一种资产,被称作过程资产,这也是企业的重要资产。
    在项目即将结束时,是一个很好的机会,对整个项目过程中的软件配置管理工作进行总结。其中的经验和教训,值得日后其他项目参考。在日后其他项目的起始阶段,制定软件配置管理工作计划时,就要考虑以往的经验和教训。
    在整个项目过程中,可能对软件配置管理流程进行了调整和改进。对这些要进行分析,看是否有可能加入到组织一级的软件配置管理流程中,从而使日后其他项目受益。在工具方面,如果引入了新的软件配置管理工具,或对已有工具进行了定制或二次开发,也要考虑,这些成果能否上升为组织一级,供日后其他项目使用。


    平衡集权与自治

    集权与自治是个古老的话题。对集权的追捧大有人在,而对自治的支持,也毫不逊色。说点公道话,其实集权有集权的好,自治有自治的好,不可以一味强调其中一端,不可偏废。古希腊的城邦政体固然好,自由、民主、独立,然后缺乏城邦之间的统一领导,邦分崩离析而不能守,最终灭亡。而柏拉图的理想国,终归只是理想国。近现代,对高度集权的经济体制的尝试,也终归只是尝试。
    对于企业运作,对于软件研发,也是同样的道理。企业,特别是高新科技企业,越来越意识到,完全的从上至下的科层体制和命令式管理是行不通的,因为基层才更了解实际情况,更知道具体问题该如何处理,更富于创造性。当然,一盘散沙式的管理也同样行不通,这会带来大量的重复劳动,恶性的内部竞争,甚至是工作目标本身的分散。
    具体到软件配置管理,也是一样。让每个产品开发团队都独自搭建一套版本控制系统,独自购买、安装、设置和备份,听起来不合理。同样,如果让企业内所有的产品研发,不论是一个人两周完成的内部工具的研发,还是一千人两年完成的大型项目的研发,都遵循同样的软件配置管理过程,这听起来问题更大。
    为什么要集权?对于软件配置管理来讲,最重要的原因有两点。首先,集权通过共享而节约了资源,节约了劳动,说白了就是省钱。就像刚才举的例子,版本控制系统的搭建和维护,是一件有一定工作量的事情,是一件有一定技术含量的事情。在公司一级统一做,只花了一分钱,只雇请了一个相应的人才。而如果几十个产品,各个都要自己搞,那就要花更多的钱,并且雇请更多的人。
    其次,车同辙,书同文,有利于沟通和交流,也方便资源的重新配置。比如,如果因为公司业务需要,一个开发人员从一个产品开发团队调到另一个产品开发团队,结果他发现,本来比较相似的产品,比较相似的产品研发,却使用了截然不同的软件配置管理工具,使用了截然不同的软件配置管理流程。于是,他不得不花大量的精力,来学习和适应。相反,如果这两个产品的研发,使用了相同或相似的软件配置管理工具和流程,这个开发人员就能把更多的精力放在软件开发本身上了。
    然后,集权和统一并不是绝对的。各个产品的研发,有它特定的背景,因为有队软件配置管理的不同程度的要求或不同方面的要求。就好像人人都要穿鞋,这是一致的,然而,各有各的尺码,不可强求,不可削足适履。至于具体如何组织和运作,要根据具体情况掌握。
    以工具为例,一般来说,一个企业的软件配置管理工具,应该统一购买、统一安装、统一设置、统一备份、统一维护和升级。总之,统一管理。这样能够降低成本,也减少企业为管理所牵扯的精力。当使用的是开源的工具或免费的工具时,虽然没有购买的问题,但仍有统一取得、统一安装等问题,仍然应该统一管理。着同样是出于成本考虑。
    有的时候,必须对取得的工具加以改造,以适应本企业的需要。这可能是通过在工具之上进行某种封装来完成,也可能在源代码级进行修改,甚至是完全自己写一个工具。这些也尽量在公司一级统一来完成,不要每个产品研发项目都尝试单搞一套。
    另一方面,不同类型的、不同背景的研发项目,对工具可能会有不同的要求。为此,可以考虑通过对工具的设置来完成,通过对工具的不同使用方法来完成。比如,有的项目使用分支,以引入多层集成,有的项目则不需要。
    如果需求差距比较远,也可以考虑使用不同的工具,比如,二三十人的小项目,而且所有人员都坐在一起开发,用svn就不错,但上千人的大项目,分布在多个研发站点的大项目,就应该考虑使用git这样的工具。即便如此,仍应该尽量减少工具的品种,比如,仅使用两种版本控制工具,一种用于内部工具开发项目,一种用于产品项目。
    流程方面也是类似的道理。几乎可以肯定的是,各产品的研发,不应该采用完全不同的软件配置管理流程和规范。同样,几乎可以肯定的是,各产品的研发不应该采用完全相同的软件配置管理流程和规范。那么,中庸之道在哪里?
    如果几个产品的研发,其背景基本相同,对软件配置管理的需求基本相同,那么它们应该遵循相似或相同的流程和规范。从这一点出发进行考虑,应该在企业级建立标准的软件配置管理流程和规范。
    对于具体产品的研发,可能需要对标准流程和规范做一些更改:可能是更细化其中的一些内容,可能是加强其中的一些内容,也可能是有所删减。这些更改,统称为流程的剪裁(Tailor)。比如,如果只有一个产品,使用了开源项目的成果,作为一个静态链接库,那么,如何管理这个静态链接库的版本等相关的方法、规范和流程,就应该写在这个产品研发本身的软件配置管理计划文档或者这个产品研发本身的流程文档里。而如果有越来越多的产品,或者预计有越来越多的产品会使用这个第三方的静态链接库,那就应该把这个静态链接库的管理,放到标准流程的规范中。
    如果某个产品的研发特点,与标准流程的适用范围非常不同,那么,裁剪可能就不再是一个有效的方法。与其把一件大人衣服改成一件洋娃娃穿的衣服,还不如为洋娃娃单做一件衣服。
    对这种情况,适宜为这个产品本身做一套流程规范,并且考虑相关工具的配合。而如果在将来要研发若干相似的产品,这套流程规范适用于或基本适用于一系列产品的研发,那么,就把这套流程规范上升为企业的标准流程规范。也就是说,这时,企业里有不止一套标准流程规范。各产品,根据自己的情况,选择相应的流程规范,并考虑进行少量裁剪。


    管理众多的项目

    当公司的产品、组件比较多了以后,管理起来,会遇到一些新的挑战。比如,存储目录结构方面的挑战:公司可能拥有多台专用服务器,每台服务器上有多个版本库,而每一个版本库里,拥有多个产品或组件的源代码。因此需要为此进行规划:设置合理的层次,进行适当的分组,并以此确定各产品、组件的存储位置。记录并遵循这样的规划。如果这样的规划需要调整,就要重新评估,重新设计方案、讨论和批准。
    不仅是源代码存储有存储结构规划的问题,对文档的存储、对安装包的存储、对静态链接库的存储,也有类似的问题。
    不仅是存储和版本控制中存在着这样的问题,变更管理,特别是变更请求管理系统中,也有类似的问题。例如,如果一个缺陷跟踪系统里,拥有数十个甚至数百个产品或组件,那么每次填写缺陷记录或查找缺陷记录时,都需要先在系统中,从这数十个甚至数百个产品或组件中,引入某种层次关系,就会大大的提高效率。而对于某个特定的团队或特定的人,一般只关心其中少数几个产品或组件,如果为此设置这几个产品或组件的某种快捷方式,会进一步提高工作效率。
    要注意,同一资产,其命名应该统一。一个源代码组件,有一个固定的名称。在版本库中,这个名称反映为存储目录名:在基线和分支中,如果需要组件的名称,那么也用这个名称;在变更请求管理工具里,也要用这个名称;生成的运行组件,还是要用这个名称。除了名称外,版本号也要对应和统一,这个我们以前也提过。


    软件配置管理团队的组织结构

    一般来说,研发软件的企业,只要企业不是太小,都会有软件配置管理团队,再不济,也会有一两名软件配置管理人员。他们的职责是什么?
    他们要负责对软件配置管理工具和环境的设置和维护。这包括工具的选型、工具的购买或取得、工具的安装、工具的设置、工具的定制和二次开发、工具的升级、工具的数据备份、工具的权限管理、工具的性能调优等。总之,是围绕软件配置管理工具的管理工作。
    除了操作和管理工具外,他们还要负责与工具相关的培训。教会每个工程师如何使用这些工具。而当大家在使用过程中遇到问题的时候,也会去请教他们,让他们帮忙解决。
    在企业级,设定专人来负责这些事情,比每个项目自己管理要好。软件配置管理工具,特别是大型商用的软件配置管理工具,管理和维护起来,可不是那么容易的。术业有专攻,还是让专人来负责整个企业这方面的事情比较好。
    除了工具需要管理,软件配置管理的流程、规范和方法也需要管理。这包括制定流程规范,也包括监督执行,还包括不断的调整和改进。请注意,这里所说的流程规范,包括标准的流程规范,也包括裁剪,还包括个别特定的规范。这些事情,谁来做呢?
    通常,公司一级的软件配置管理人员,应该发挥重要作用,因为它更专业,更能照顾全局。而在具体项目中,项目中的配置管理人员也应该发挥作用,因为项目成员更了解本项目的实际情况。一般的标准流程规范,应该由公司一级的软件配置管理人员负责起草、发布并持续改进,并征询各方意见。而具体项目中对标准流程规范的裁剪,公司一级的软件配置管理人员可以只是参与。
    企业的软件配置管理人员,应该对员工进行软件配置管理方面的流程培训,仅有工具培训是不够的。要教会每个工程师,如何在这些流程下规范的工作。而当大家在工作过程中遇到问题的时候,也要去请教软件配置管理人员。
    对流程和规范的监督执行,也就是常说的流程审计,可以由软件配置管理人员进行,也可以由质量保证部门进行。而在各个项目研发团队内部,可能还有自查。
    与公司级的软件配置管理人员相对应的,是项目或产品一级的软甲配置管理人员。他们负责项目或产品整个生命周期中的软件配置管理,从制定软件配置管理计划开始。他们还可能会负责产品之间的协调工作,当然这也可能是由企业级的软件配置管理人员完成的。
    事实上,项目或产品一级的软件配置管人员,也有可能在行政上归属于企业级的软件配置管理团队。或者,项目及的软件配置管理人员与企业级的软件配置管理人员,仅仅是角色的划分,实际上是同一个人。
    集成工程师,包括组建级的集成工程师和系统级的集成工程师,他们的主要职责是集成,以及与集成相关的一些操作。他们可能由软件配置管理人员兼任。
    然后,配置管理人员绝不要把集成、发布等工作当作自己职责的全部。配置管理人员最基本的任务,是建立、维护、调整和改进配置管理解决方案,包括流程、工具、人,保证配置管理系统的运行和不断调优。其中非常重要的一点是,设置正确的、符合企业特定环境特定需求的配置管理策略。让我们为此共同努力!

    展开全文
  • was 配置

    千次阅读 2016-08-16 16:10:31
    原文地址:... 在 UNIX 和 Linux 系统上安装和配置 WebSphere Application Server UNIX 和 Linux 是最适合 WebSphere 的平台 学习如何在现代企业环境中使用应用服务器以及如何在 UNI

    原文地址:https://www.ibm.com/developerworks/cn/aix/library/au-wasonlinux/

    在 UNIX 和 Linux 系统上安装和配置 WebSphere Application Server

    UNIX 和 Linux 是最适合 WebSphere 的平台

    学习如何在现代企业环境中使用应用服务器以及如何在 UNIX® 和 Linux® 系统上安装 IBM® WebSphere® Application Server,从而提供健壮的具有良好支持的企业 Web 环境的基础。本教程还解释如何在 UNIX 和 Linux 服务器的启动和关闭过程中集成 WebSphere Application Server,并提供许多其他参考资料的链接,帮助您快速地设置和运行 WebSphere Application Server。

    William von Hagen, 系统管理员,作家, WordSmiths

    2009 年 3 月 16 日

    • expand内容

    开始之前

    本节解释本教程讲授什么内容,以及如何从中获得最大的收益。

    关于本教程

    应用服务器是当今企业计算环境中使用的 Web 体系结构的核心组件。本教程首先讨论当今 Web 体系结构中的中间件,重点是 IBM 的 WebSphere 系列产品以及部署 WebSphere Application Server 的各种方式。然后,详细介绍如何安装和配置 WebSphere Application Server 以及如何把它集成在系统的启动过程和企业计算基础结构中。学完本教程之后,您将会理解如何安装、配置和部署 WebSphere Application Server 以及它与 Web 计算环境中的其他应用程序和服务器的关系。

    目标

    本教程:

    • 概述常见的 Web 体系结构以及应用服务器和中间件在当今企业 Web 体系结构中的作用。
    • 介绍 WebSphere Application Server 的基本知识。
    • 概述和对比常见的 WebSphere 安装和部署机制。
    • 讲解如何在 UNIX 和 Linux 发行版上安装 WebSphere Application Server。
    • 简要概述 WebSphere Application Server 的初始配置。
    • 详细介绍如何把 WebSphere Application Server 集成在系统启动和关闭过程中,以及如何手工启动和停止服务器。

    前提条件

    本教程是为初级和中级系统管理员撰写的,他们可能没有安装或配置过 Web 应用服务器,可能不熟悉现代 Web 服务器体系结构。为了完成本教程中的示例,您应该基本熟悉 UNIX 命令行 shell 和文本编辑器。

    系统需求

    为了运行本教程中的示例,您需要拥有一个 UNIX 或 Linux 系统的管理(root)特权,此系统上当前没有安装应用服务器,它应该有至少 1GB 的 RAM。

    在安装 WebSphere Application Server 时,系统上必须有至少 3.1GB 的可用磁盘空间:在包含 /opt 目录的文件系统中必须有至少 1.3GB 的永久可用空间,在执行 WebSphere Application Server 安装的文件系统中必须有至少 1.75GB 的临时可用空间。

    如果要在 Linux 系统上安装 WebSphere Application Server,应该注意并非所有 Linux 发行版都包含适合安装程序和某些 WebSphere Application Server 功能使用的 Java™ Runtime Environment (JRE) 版本。在不支持的 Linux 发行版(比如 Ubuntu)上,应该下载并安装 IBM Java software development kit (SDK),再对系统做一些修改,然后才能安装 WebSphere Application Server。具体步骤参见 设置不支持的 Linux 发行版

    如果选择安装 IBM Java SDK,那么系统上必须还有至少 450MB 的磁盘空间:在包含 /opt 目录的文件系统中必须有至少 175MB 的永久可用空间,在执行 IBM Java SDK 安装的文件系统中必须有至少 275MB 的临时可用空间。

    Web 服务器和体系结构

    与几年前简单的内容交付模型相比,当今的企业 Web 环境要复杂得多。Web 软件技术不断发展,Web 服务器和其他数据源之间的连接日益增加,这些使用户能够通过 Internet 做的事情和企业能够通过 Web 提供和使用的服务发生了革命性变化。

    现代 Web 体系结构和中间件

    当今的企业 Web 环境使用所谓的 n 层体系结构,这使 Web 服务器能够连接各种数据源,而不限于简单的静态内容。为了访问远程数据源,这些 n 层 Web 体系结构通常使用中间件,“中间件” 这个术语表示连接其他应用程序或服务的软件。最强大最灵活的中间件形式是 Web 应用服务器,比如 WebSphere Application Server,Web 应用服务器上驻留企业 Web 应用程序所需的应用程序编程接口 (API)。这些 Web 应用程序实现应用程序和资源(业务逻辑 )之间的连接,从而满足各种基于 Web 的业务过程 实现的需要。

    在 n 层 Web 体系结构中,应用服务器可以在运行 Web 服务器的系统上运行,也可以在另一个系统上运行。Web 服务器作为 Web 客户机和应用服务器之间的中介,而应用服务器作为应用程序逻辑和远程数据之间的中介。

    IBM WebSphere Application Server 概述

    IBM WebSphere Application Server 是一种 Java 应用服务器,它是使用 Java Platform, Enterprise Edition (Java EE)、Extensible Markup Language (XML) 和基于 Hypertext Transfer Protocol (HTTP) 的 Web 服务等开放标准构建的。WebSphere Application Server 通常与其他 IBM 产品结合使用,比如 IBM HTTP Server,但是也可以与大多数其他 Web 服务器一起使用,包括标准的 Apache HTTP Server、Microsoft® Internet Information Services (IIS) 和 Sun Java System Web Server。IBM HTTP Server 包含一个 WebSphere Application Server 插件,它可以简化 WebSphere 的配置和管理。

    WebSphere Application Server 为企业 Web 应用程序提供一个健壮的可伸缩的环境。它的体系结构以及其他 WebSphere 产品提供的重用和集成机会有助于减少运行时内存需求,为基于 Web 的应用程序开发和部署提供可靠的基于标准的基础结构。目前有许多 WebSphere 附加产品,它支持多种开发框架,支持 Service Component Architecture (SCA) 等新标准,这些特点有助于满足当今企业应用程序的需求,简化新应用程序的开发和集成,从而提供未来需要的解决方案。参考资料 中提供了 WebSphere Application and transaction infrastructure 页面的链接,这个页面提供当前可用的许多 WebSphere 附加产品的相关信息。

    在许多平台上都支持 IBM WebSphere Application Server 和 IBM HTTP Server,包括 Linux、IBM AIX®、HP-UX、IBM i (i5/OS、i6/OS、OS/400)、IBM z/OS、Microsoft Windows® 和 Solaris。关于硬件和软件需求的详细信息请参见 支持的平台 一节。

    关于流行的 n 层应用服务器的更多信息请参见 参考资料 中的链接。

    支持的平台

    本教程讨论如何安装和配置 IBM WebSphere Application Server 7.0。在以下操作系统和相关硬件上支持 7.0 版:

    • AIX
    • HP-UX on IA64 和 HP-UX PA-RISC
    • Linux(32 位)
    • Linux for IBM i™, System p™, and System z™
    • Sun Solaris on SPARC and x86-64
    • Microsoft Windows 2000、Windows Server® 2003 和 Microsoft Windows XP

    WebSphere Application Server 在 Red Hat Enterprise Linux 4 和 5 以及 SuSE Enterprise Server 9 和 10 种 Linux 发行版上得到正式支持,但是应该能够在任何 Linux 发行版上简便地安装它。设置不支持的 Linux 发行版 一节讲解在没有得到正式支持的 Linux 发行版上如何安装和运行 WebSphere Application Server。

    注意:在 64 位的 UNIX 系统上,只要安装了 UNIX 系统的 32 位兼容库,就可以运行 WebSphere Application Server 和 HTTP Server 的 32 位 Intel® 体系结构版本。在不同的 UNIX 系统上,这个包的名称和安装所用的包管理系统不一样。在 Linux 系统上,这是 ia32-libs 包。

    部署 WebSphere Application Server

    通常,按照两种基本方式之一部署 WebSphere Application Server:

    • 作为单独的应用服务器部署,这在单一服务器环境中支持特定的业务逻辑和相关应用程序。
    • 在网络部署场景中,应用服务器集群提供高级功能,从而实现高性能、高可用的环境。(更多信息参见 参考资料)。

    随着业务需求和信息技术 (IT) 基础结构的增长,可以把单独的 WebSphere Application Server 系统集成到网络部署场景中创建的集群中。

    由于网络部署取决于站点的具体情况,本教程主要讨论如何安装单独的应用服务器。

    安装 WebSphere Application Server

    由于 WebSphere Application Server 具有图形化的安装程序,所以安装它非常简单。

    获取安装文件

    如果希望在特定的 UNIX 系统上试用 WebSphere Application Server,可以向 IBM 索取评估版。更多信息请询问 IBM 销售代表。

    设置不支持的 Linux 发行版

    本教程的 支持的平台 一节列出了正式支持 WebSphere Application Server 的 UNIX 和 Linux 平台。作为商业产品,UNIX 系统提供标准的功能,可以保证 WebSphere Application Server 等商业产品要使用的功能是存在的。但是,各个 Linux 发行版差异很大,所以 WebSphere Application Server 只在某些发行版上得到正式支持。尽管如此,只需对其他 Linux 发行版稍做修改,即可在这些系统上运行 WebSphere Application Server。

    注意:如果要在 UNIX 或支持的 Linux 平台上安装 WebSphere Application Server,那么可以跳过本节,直接跳到本教程的 提取文件并开始安装一节。

    例如,并非所有 Linux 发行版都包含适合 WebSphere Application Server 安装程序和某些 WebSphere Application Server 功能使用的 JRE 版本。在不支持的 Linux 发行版(比如 Ubuntu)上,应该下载并安装 IBM Java SDK,供安装期间使用。可以通过 参考资料 中提供的一个链接下载适用于您的平台的 IBM Java SDK 版本。下载此文件之后,按照以下步骤提取它的内容并安装它:

    1. 使用下面这样的命令提取存档文件的内容 :

      tar zxvf filename.tar.gz

      把 filename 替换为您下载的 IBM Java SDK 存档文件的名称,比如 ibm-java-sdk-6.0-2.0-linux-x86_64.tar.gz。这个 tar 命令会创建一个目录,比如 ibm-java-x86_64-60。

    2. 使用 sudo 命令和下面这样的命令把从存档文件中提取出的目录转移到一个系统目录(比如 /opt):

      mv DIRECTORY /opt

      把 DIRECTORY 替换为在提取 IBM Java SDK 存档文件内容时创建的目录。

    3. 使用下面这样的命令修改系统搜索二进制代码的目录:

      export PATH DIRECTORY:$PATH

      应该把此命令添加到 shell 启动文件 (~/.bashrc) 中,从而确保以后使用 JRE 的这个版本。

    在 Ubuntu 系统上,还必须修改默认的 shell,它映射到通用的 UNIX/Linux shell,/bin/sh。Ubuntu 系统使用一个名为 /bin/dash 的轻型 shell 作为 /bin/sh,但是这个 shell 没有提供 WebSphere Application Server 安装和启动脚本所需的所有功能。为了使用标准的 Bash shell 作为 /bin/sh,应该在 Ubuntu 系统上执行以下命令,然后才能开始 WebSphere Application Server 的安装过程:

    sudo mv /bin/sh /bin/sh.ORIG
    sudo ln -s /bin/bash /bin/sh

    执行这些步骤之后,就能够在 Ubuntu 系统上开始 WebSphere Application Server 安装过程。其他 Linux 发行版可能需要相似的修改。

    提取文件并开始安装

    建议在 /opt/WASTrial 目录中提取实际安装 WebSphere Application Server 所用的文件。按照以下步骤创建此目录:

    1. 根据要安装 WebSphere Application Server 的系统是 UNIX 系统还是 Linux 发行版,使用 su 或 sudo -s 命令变成系统的特权用户。在出现提示时,分别输入根密码或您的密码??
    2. 使用 mkdir /opt/WASTrial 命令创建 /opt/WASTrial 目录。
    3. 切换到 /opt/WASTrial 目录。
    4. 使用 tar 命令提取下载的文件内容。

      如果下载了文件,那么使用下面这样的命令:

      tar zxvf /path/to/file/was.cd.7000.trial.base.linux.ia32.tar.gz

      把 /path/to/file 替换为下载的文件的完整目录路径。

    5. 使用 ./launchpad.sh 命令启动 Firefox Web 浏览器,这会显示 图 1 所示的页面。
      图 1. Firefox 欢迎页面
      Firefox 欢迎页面

    注意:如果使用 Linux 进行评估,那么没有 64 位的 Linux 版本可供下载。支持的平台 一节解释了如何在 64 位 Linux 系统上使用 32 位 Linux 版本。   这里点击启动可能没反应 需要安装compat-libstdc++-33-3.2.3-61.i386.rpm 

    启动安装程序

    单击 Launch the installation wizard for WebSphere Application Server Trial 启动实际安装过程。WebSphere Application Server 的图形化安装程序启动,显示它的欢迎页面,见 图 2

    图 2. WebSphere Application Server 安装程序的欢迎页面
    WebSphere Application Server 安装程序的欢迎页面

    欢迎页面说明图形化安装程序工作正常,它还提供一些在线站点的链接,这些站点提供 WebSphere 和相关产品的信息和支持。

    单击 Next 继续安装过程。

    接受许可条款并检查系统

    图形化安装程序的下一个页面显示 WebSphere Application Server 采用的许可协议,见 图 3

    图 3. 接受 IBM 软件许可协议
    接受许可条款

    这个许可协议包含 WebSphere Application Server 评估版的 IBM 许可协议信息和语言,这些条款不包含随 WebSphere Application Server 发布的开放源码软件,许可协议会指出采用单独许可协议的软件组件。

    选择 I accept the terms in the licensing agreement 接受许可条款。单击 Next 继续安装过程。如果不接受许可条款,就会显示一个窗口,要求您确认这一点。如果确认不接受许可条款,那么安装程序退出。

    安装程序的下一个页面指出您的系统是否满足安装的前提条件。如果系统不满足需求,安装程序可能会指出应该安装哪些补丁。在这种情况下,可以单击 Cancel 退出安装程序并安装缺少的软件,也可以继续安装。

    单击 Next 继续安装过程。

    选择要安装的可选特性

    在 图 4 所示的安装程序屏幕上,可以选择在安装 WebSphere Application Server 时要安装的可选软件。

    图 4. 选择要安装的可选特性
    选择要安装的可选特性

    可以安装的可选软件包括:

    • 示例应用程序:用于实验的源代码和集成的应用程序。还可以使用示例应用程序检查 WebSphere Application Server 是否已经成功地安装并在系统上正确地运行了。
    • 管理控制台的非英语支持:为 WebSphere Application Server 的管理控制台提供国家语言支持的语言目录。这些语言目录并不为 WebSphere Application Server 本身提供国家语言支持,这由此屏幕上的另一个选项提供。
    • WebSphere Application Server 的非英语支持:为 WebSphere Application Server 本身提供国家语言支持的语言目录。这些语言目录并不为 WebSphere Application Server 的管理控制台提供国家语言支持,这由此屏幕上的另一个选项提供。

    除非您已经非常熟悉 WebSphere Application Server,否则应该安装示例应用程序,通过这些程序进一步了解 WebSphere Application Server 环境中的应用程序集成和部署。

    WebSphere 安装的默认语言包是美国英语。是否安装可选语言包取决于您的地理位置和语言支持需求。管理控制台和 WebSphere Application Server 语言支持包支持的其他语言包括 Chinese、Czech、French、German、Hungarian、Italian、Japanese、Korean、Polish、Portuguese、Russian 和 Spanish。

    选择要安装的可选特性之后,单击 Next 继续安装过程。

    指定目标安装目录

    接下来,图形化安装程序显示安装 WebSphere Application Server 的默认位置,在 UNIX 和 Linux 系统上此位置是 /opt/IBM/WebSphere/AppServer。图 5 显示此屏幕。

    图 5. 指定安装位置
    指定安装目录

    注意:不建议改变此位置,因为在非标准位置安装 WebSphere Application Server 会导致本地系统管理更加复杂。一些 WebSphere 应用程序可能需要标准安装位置,非标准安装位置可能会使这些应用程序出现问题。

    单击 Next 继续安装过程。

    指定 WebSphere Application Server 环境

    在 图 6 所示的屏幕上,可以指定在安装过程中要创建的 WebSphere Application Server 环境的类型。

    图 6. 指定目标服务器环境
    指定目标服务器环境

    环境 是指安装和集成 WebSphere Application Server 的管理和网络环境。选择的环境将决定在安装过程中自动创建的执行配置文件的类型(或是否创建执行配置文件)。选项包括:

    • Management:如果要用 WebSphere Application Server 管理本地机器或网络上其他系统上的其他应用服务器环境,就选择此选项。选择此选项会创建适当的配置文件,安装和配置一个管理代理服务器、用于管理多个应用服务器环境的服务以及管理同一计算机上其他应用服务器的管理代理。
    • Application server:这是默认选项,它为安装单独的应用服务器创建适当的配置文件,应用服务器将运行您自己的企业应用程序,只能从它的管理控制台管理它。
    • None:如果不希望在安装期间创建执行配置文件,就选择此选项。只有在希望在系统上成功安装 WebSphere Application Server 之后显式地创建一个或多个配置文件的情况下,才应该选择此选项。

    单击 Next 继续安装过程。

    注意:如果选择 None 作为服务器执行环境,就会显示一个警告对话框,它指出要想运行 WebSphere Application Server,必须至少有一个有效的配置文件。单击 Yes 继续安装过程,但不在安装过程中创建配置文件,这会前进到 汇总页面和实际安装 一节解释的页面。如果希望在安装过程中创建配置文件,那么单击 No 返回到 图 6 所示的对话框,修改服务器执行环境设置。

    创建管理用户

    在安装程序的下一个屏幕(见 图 7)上,可以创建一个安全账户,此账户用于通过 WebSphere Application Server 管理控制台进行系统管理。

    图 7. 创建管理用户
    创建管理用户

    如果要安装单独的或受管理的 WebSphere Application Server(换句话说,在安装 WebSphere Application Server 的过程中,要按照 指定 WebSphere Application Server 环境 中的说明创建配置文件),就要创建管理用户。

    输入用于管理 WebSphere Application Server 的用户名和密码,再次输入密码以确认第一次输入的密码是正确的。

    如果在 选择要安装的可选特性 一节选择了示例应用程序,那么还会提示您设置与这些示例应用程序相关联的用户的密码。输入密码两次以确保输入是正确的。

    在提供管理用户的相关信息(以及可选的示例应用程序密码)之后,单击 Next 继续安装过程。

    汇总页面和实际安装

    如 图 8 所示,一个汇总屏幕显示您已经接受或指定的配置选项并提供一个复选框,让您能够检查是否有执行安装所需的特权。

    图 8. 关于安装配置的信息
    关于安装配置的信息

    在大多数情况下,作为 root 用户执行安装,所以不需要检查是否有所需的特权。清空此复选框并单击 Next 开始安装过程。一个窗口显示安装过程的状态。安装过程首先创建 WebSphere Application Server 的卸载程序,从而简化软件的删除。然后安装 WebSphere Application Server,在安装过程中显示状态信息。

    安装状态和后续步骤

    在安装完成时,图 9 所示的窗口显示安装是否成功。如果出现任何错误,此窗口显示日志文件的位置,可以通过检查日志文件寻找问题并判断它们是否有意义。

    图 9. 关于安装的总结信息
    关于安装的总结信息

    此屏幕提供一个复选框,因为在默认情况下它是被选中的,在退出安装程序时会启动 WebSphere Application Server First steps 控制台。在 First steps 控制台上,可以对 WebSphere Application Server 做一些初始配置。

    此时,有两个选择:

    • 保持 Launch the First steps console 复选框的选中状态并单击 Finish,从而退出安装程序并启动 First steps 控制台。
    • 清空 Launch the First steps console 复选框并单击 Finish,从而退出安装程序,但是不启动 First steps 控制台或 WebSphere Application Server。

    恭喜:您已经安装了 WebSphere Application Server。如果启动了 First steps 控制台,请阅读下一节,了解如何使用这个控制台。否则,可以执行以下操作:

    • 手工启动 WebSphere Application Server。
    • 集成 WebSphere Application Server 与系统的 Web 服务器。
    • 把 WebSphere Application Server 集成到系统的启动和关闭过程中。
    • 访问 WebSphere 管理控制台,开始配置 WebSphere Application Server。

    使用 First steps 控制台

    WebSphere Application Server 安装过程可以自动启动 First steps 控制台,帮助用户熟悉 WebSphere Application Server 并执行一些初始配置任务。图 10 显示 First steps 控制台的初始屏幕。

    图 10. First steps 控制台
    First steps 控制台

    如 图 10 所示,First steps 控制台提供许多任务的链接,在安装之后可能希望马上执行这些任务,包括:

    • 安装检验检验 WebSphere Application Server 的安装,确认安装正确并在这个过程中启动应用服务器。
    • 启动服务器启动 WebSphere Application Server,为了提供方便和帮助判断问题,在一个单独的窗口中显示启动过程的输出。当应用服务器开始运行之后,此链接会变成 Stop the server 链接,这提供一种停止服务器的简便方法并在一个单独的窗口中显示服务器关闭过程的输出。停止服务器需要 在安装过程中设置的管理密码,这是对应用服务器的内部身份验证机制进行检查的简便方法。
    • 管理控制台在浏览器窗口中启动 WebSphere 管理控制台,可以在这个控制台上执行安装过程中没有涉及到的配置任务。启动管理控制台也需要 在安装过程中设置的管理密码
    • 配置文件管理工具:可以创建额外的执行配置文件,每个配置文件可以针对特定的企业 Web 应用程序、端口配置等。如果没有 在安装过程中指定目标服务器环境,而且没有从现有的 WebSphere Application Server 系统迁移服务器配置信息,那么使用此选项创建至少一个 WebSphere Application Server 配置文件。至少要有一个配置文件,才能启动 WebSphere Application Server — 每个配置文件提供在一种特定上下文中启动应用服务器所需的配置信息。
    • 示例库:访问 在安装过程中安装的 示例应用程序。
    • WebSphere Application Server 信息中心:在浏览器中打开 WebSphere Application Server Library 网站,这里提供关于 WebSphere Application Server 的详细信息,涉及许多不同的企业应用程序场景。
    • 迁移向导:这个向导帮助用户从以前的 WebSphere Application Server 版本迁移配置信息和应用程序。

    下面几节详细讨论 First steps 控制台提供的选项。

    安装检验

    如果在 WebSphere Application Server 安装过程中出现任何错误,就会显示错误消息。尽管如此,仍然应该再次检查应用服务器的安装是否完成,以及在安装过程中是否正确地创建了所需的所有配置文件。

    为了检查是否已经在系统上正确地安装了 WebSphere Application Server 并在测试过程中启动它,单击 First steps 控制台中的 Installation verification 链接。这时会显示 图 11 所示的窗口。

    图 11. 检验过程的输出
    检验过程的输出

    如图所示,检验过程首先用默认的配置文件启动应用服务器,然后连接应用服务器,从而检查 Servlet 引擎、JavaServer pages 和企业 bean 配置。然后检查键存储的身份验证,键存储用于在 WebSphere 组件之间提供安全的连接。

    在检验过程完成时,可以单击输出窗口右上角的关闭按钮,从而关闭窗口并返回到 First steps 控制台。注意,Start the server 链接已经变成Stop the server 链接,这是因为在检验过程中启动了 WebSphere Application Server。

    启动服务器

    如果没有按照 前一节 中的说明检验 WebSphere Application Server 安装,可以通过单击 First steps 控制台中的 Start the server 链接手工启动 WebSphere Application Server。单击此链接就会显示与 图 11 非常相似的输出窗口,但是其中只显示服务器启动过程的相关信息,而不检验服务器的配置。

    注意:如果 First steps 控制台没有显示 Start the server 链接,而是显示 Stop the server 链接,就说明 WebSphere Application Server 已经启动了。

    在输出窗口显示 ADMU3000I: Server NAME open for e-business... 这样的文本行之后,可以单击输出窗口右上角的关闭按钮,从而关闭窗口并返回到 First steps 控制台。

    管理控制台

    WebSphere Application Server 管理控制台是配置应用服务器、集成应用服务器和外部应用程序(比如数据库系统)以及安装 WebSphere 应用程序的主要机制。如果您刚刚接触 WebSphere Application Server,希望研究管理控制台或者在安装 WebSphere 之后马上安装新的 WebSphere 应用程序,可以从 First steps 控制台启动管理控制台。

    在 First steps 控制台中,单击 Administrative console 启动 WebSphere Application Server 管理控制台。管理控制台的登录屏幕在浏览器窗口中打开,见 图 12

    图 12. 管理控制台的登录屏幕
    管理控制台的登录屏幕

    管理控制台需要 Secure Sockets Layer (SSL) HTTP 连接,这一般是指 Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) 连接。只有在系统上安装了有效的第三方 SSL 证书的情况下,才会显示 图 12 所示的页面。如果在安装 WebSphere Application Server 的系统上没有第三方发布的有效证书,就会看到 图 13 所示的警告对话框。

    图 13. 证书不可信警告
    证书不可信警告

    如果看到这个消息,请阅读本教程的下一节,了解如何为系统现有的证书 配置安全例外

    如果看到 图 12 所示的管理控制台登录屏幕,那么输入 在安装过程中定义的管理用户名和密码 并单击 Login 或按回车。这时显示 WebSphere Application Server 管理控制台,见 图 14。尝试使用管理控制台,完成后单击 Logout 链接。

    图 14. 管理控制台
    管理控制台

    配置证书的安全例外

    正如 前一节 中提到的,WebSphere Application Server 管理控制台需要一个 SSL HTTP 连接,这一般是指 HTTPS 连接。根据大多数系统使用的默认安全策略,这意味着系统上的公共密钥安全证书必须是由可信的第三方证书机构发布的有效证书,可信的第三方证书机构包括 thawte、VeriSign、GeoTrust 等等。关于这些第三方证书机构的更多信息请参见 参考资料

    在生产环境中,肯定只希望在具有有效的企业或第三方安全证书的系统上使用 WebSphere Application Server,这样 Web 应用程序的用户就能够确认他们连接的系统的身份。但是,可能要在还没有证书的新系统上安装和配置 WebSphere Application Server。在这种情况下,可以临时或永久地把现有的证书定义为可信的证书,这是标准 WebSphere 安全策略的例外。

    为了定义策略例外,在 图 13 所示的对话框中单击 OK,显示 图 15 所示的屏幕。

    图 15. Firefox 中的安全连接失败
    Firefox 中的安全连接失败

    单击 Or you can define an exception 链接,开始把系统的证书指定为有效数字公共密钥证书的过程。这时会显示一个与当前屏幕相似的屏幕,其底部显示两个额外的按钮。单击 Add exception 继续把当前证书定义为默认证书策略的例外的过程。这时显示 图 16 所示的对话框。

    注意:单击 Get me out of here! 按钮就会退出例外定义过程并返回到浏览器,而没有建立到 WebSphere 管理控制台的连接,这对于本教程是没有影响的。

    图 16. 用于定义安全例外的初始对话框
    用于定义安全例外的初始对话框

    单击 Get Certificate 获取系统的当前证书,这会显示当前证书的相关信息并启用 图 16 所示的对话框左下角的 Confirm Security Exception按钮,见 图 17

    图 17. 用于定义安全例外的更新后的对话框
    用于定义安全例外的更新后的对话框

    通过使用 Confirm Security Exception 按钮上面的 Permanently store this exception 复选框,可以指定是把当前证书永久存储为安全策略的例外,还是只在当前会话中接受它。在配置生产系统时,不要选中这个复选框,这样就必须总是执行安全例外定义过程,从而避免忘记在运行 WebSphere Application Server 的系统上安装有效证书。如果您使用的是不会在生产环境中使用的测试系统,那么可以保持 Permanently store this exception 复选框的选中状态。

    单击 Confirm Security Exception 按钮把当前证书定义为安全策略的例外。这时显示 WebSphere Application Server 管理控制台登录屏幕,见图 12。然后,可以输入 在安装过程中定义的管理用户名和密码 并单击 Login 或按回车,从而进入 WebSphere Application Server 管理控制台,见 图 14。尝试使用管理控制台,完成后单击 Logout 链接。

    示例库

    单击 First steps 控制台中的 Samples gallery 链接就会显示 图 18 所示的页面。可以通过这个页面尝试在 WebSphere Application Server 安装过程中可选安装的 示例应用程序

    图 18. 示例应用程序库
    示例应用程序库

    可以执行或修改这些示例,从而体会如何编写 WebSphere 应用程序以及在基于 WebSphere 的环境中如何显示和执行它们。最有意思的示例应用程序是在线 Java Pet Store,可以通过这个应用程序在线浏览和购买产品。

    体验示例应用程序之后,只需关闭浏览器窗口,返回到 First steps 控制台。

    关闭 WebSphere Application Server

    在体验了 First steps 控制台上提供的各种选项之后,可以停止应用服务器,以便尝试手工启动应用服务器,或者把 WebSphere Application Server 的启动和停止集成在系统的启动和关闭过程中(参见本教程的 下一节)。为了从 First steps 控制台停止 WebSphere Application Server,单击 First steps 控制台中的 Stop the server 链接。单击此链接就会显示 图 19 所示的身份验证对话框。

    图 19. 停止应用服务器的身份验证对话框
    停止应用服务器的身份验证对话框

    输入 在安装过程中设置的管理用户名和密码,单击 OK 开始应用服务器关闭过程。显示 图 20 所示的对话框,其中显示关闭过程的输出。

    图 20. 应用服务器停止过程的输出
    应用服务器停止过程的输出

    在输出窗口显示 ADMU4000I: Server NAME stop completed 这样的文本行之后,可以单击输出窗口右上角的关闭按钮,从而关闭窗口并返回到 First steps 控制台。

    启动和停止 WebSphere Application Server

    安装 WebSphere Application Server 并不会在系统上启动 WebSphere Application Server 进程。正如前一节提到的,在默认情况下 First steps 控制台在安装过程结束时提供一种马上启动 WebSphere Application Server 的简便方法。但是,在完成安装过程并退出这个控制台之后,这种启动方法就没什么价值了。

    本节解释如何手工启动和停止 WebSphere Application Server,以及如何把 WebSphere Application Server 的启动和停止集成在系统的启动和关闭过程中。如果使用 WebSphere Application Server 执行实际工作或长期实验,可能希望在启动系统时自动启动它,在关闭系统时自动关闭它。

    WebSphere Application Server 提供一些方便的 UNIX/Linux shell 脚本,它们可以简化从命令行或其他脚本(比如在系统的启动和关闭过程中运行的脚本)启动和停止应用服务器的过程。

    启动 WebSphere Application Server

    WebSphere Application Server 提供 startServer.sh shell 脚本以简化应用服务器的启动过程。此脚本有一个参数,即要启动的应用服务器的名称。在刚安装 WebSphere Application Server 的系统上,默认的服务器名称是 server1

    启动应用服务器的方法是,使用 su 或 sudo -s 命令(取决于使用的是 UNIX 系统还是 Linux 发行版)变成安装 WebSphere Application Server 的系统上的特权用户。在出现提示时,分别输入根密码或您的密码。

    接下来,输入以下命令启动 WebSphere Application Server:

    /opt/IBM/WebSphere/AppServer/bin/startServer.sh server1

    在应用服务器启动时,会看到与 图 11 所示的输出窗口相似的输出。当服务器启动过程完成,应用服务器准备好使用时,再次显示命令提示。

    系统启动和关闭的集成

    在系统上安装应用服务器之后,通常希望在每次重新启动系统时自动启动它。在 Microsoft Windows 等平台上安装 WebSphere Application Server 时,安装过程允许用户把服务器和管理服务器定义为在启动系统时自动启动的 Windows 服务。但是,UNIX 和 Linux 安装程序没有提供相似的启动集成机制。因此,在 UNIX 和 Linux 系统上,必须手工地把 WebSphere Application Server 集成到系统启动过程中。

    所有 UNIX 和 Linux 系统都有一系列在系统启动时执行的 shell 脚本(通常称为 init 脚本),通过它们定义应该在启动和关闭过程中执行的任务。在大多数 UNIX 和 Linux 系统上,按照 SysVInit(即 System V Init,这是指 UNIX 的一个老版本)系统启动机制指定的方式组织这些脚本(更多信息请参见 参考资料)。按照这种机制,系统的主要启动脚本都放在 /etc/init.d 中(在某些系统上,此目录可能是 /etc/rc.d/init.d 目录的符号链接)。在系统引导时执行的针对特定操作级(称为 runlevel)的脚本是符号链接,它们把 /etc/rcrunlevel.d 目录中的脚本链接到 /etc/init.d 目录中的脚本。Ubuntu Linux 系统使用另一种与 SysVInit 过程兼容的启动机制,后面一节 解释这种机制。

    创建 SysVInit 脚本

    为了为 WebSphere Application Server 创建 SysVInit 脚本,可以采用以下方法之一:

    • 下载本教程提供的示例 SysVInit 脚本。
    • 复制并修改现有的 init 脚本,让它执行与 WebSphere Application Server 相关联的进程。

    本节的其余部分解释如何下载和使用本教程提供的示例 SysVInit 脚本,见 清单 1

    清单 1. 示例 SysVInit 脚本
    #!/bin/bash
    #
    # Simple startup script for IBM WebSphere Application Server
    #
    # chkconfig: - 85 15
    # description: IBM WebSphere Application Server is a powerful \
    # middleware platform for connecting Web-based applications and \
    # servers.
    
    # Path to the WebSphere startup and shutdown scripts
    startscript=/opt/IBM/WebSphere/AppServer/bin/startServer.sh
    shutscript=/opt/IBM/WebSphere/AppServer/bin/stopServer.sh
    prog="the WebSphere Application Server"
    RETVAL=0
    
    # modify the following line as needed to reflect any custom Java
    # installation directory
    PATH=/opt/IBM/ibm-java-x86_64_60/bin:$PATH
    
    # Function to start the server 
    start() {
      echo -n $"Starting $prog: "
      $startscript server1
      RETVAL=$?
      echo
      return $RETVAL
    }
    
    # Function to stop the server
    stop() {
      echo -n $"Stopping $prog: "
      $shutscript server1 -username ADMINUSER -password PASSWORD
      RETVAL=$?
      echo
      return $RETVAL
    }
    
    # See how we were called.
    case "$1" in
      start)
        start
        ;;
      stop)
        stop
        ;;
      restart)
        stop
        start
        ;;
    *)
      echo $"Usage: $0 {start|stop|restart}"
      exit 1
    esac
    
    exit $RETVAL

    按照以下步骤下载和安装示例 SysVInit 脚本:

    1. 下载示例脚本。
    2. 作为根用户(或通过使用 sudo 命令)把此文件保存到系统上的 /etc/init.d 目录中,把它命名为 websphere_sysvinit.sh
    3. 使用文本编辑器编辑它,把 ADMINUSER 和 PASSWORD 改为 在安装过程中定义的管理用户名和密码 并保存这些修改。
    4. 作为根用户或使用 sudo 命令,使用以下命令设置文件的可执行权限:
      chmod 755 /etc/init.d/websphere_sysvinit.sh
    5. 通过使用下面这样的命令,在与系统的默认运行级相关联的目录中创建此文件的符号链接(/etc/rc5.d 目录通常用于图形化系统,/etc/rc3.d 目录用于使用文本控制台的系统):
      ln -s /etc/init.d/websphere_sysvinit.sh /etc/rc5.d/S85ibm-was
      ln -s /etc/init.d/websphere_sysvinit.sh /etc/rc5.d/K15ibm-was

    在下一次关闭系统时,这里创建的 K15ibm-was 符号链接会在关闭过程中自动停止 WebSphere Application Server。在下一次启动系统时,S85ibm-was 符号链接会在启动过程中自动启动 WebSphere Application Server。

    创建 Ubuntu Upstart 脚本

    Ubuntu Linux 发行版使用一种与 SysVInit 机制不同的启动机制。Ubuntu 启动机制称为 Upstart(参见 参考资料),这是一种为 Ubuntu 创建的非常新的事件驱动的启动机制,但是 Fedora、Red Hat 和 Centos 等其他发行版也将采用这种机制。Upstart 由于支持并发性和响应系统事件而广受欢迎。

    目前,Upstart 的实现与传统的 SysVInit 模型兼容。在 下载 中可以找到一个简单的 Upstart 脚本,可以把它放在系统的 /etc/init.d 目录中并用它启动 WebSphere Application Server。此脚本的代码见 清单 2

    清单 2. 示例 Upstart 脚本
    #!/bin/bash -e
    ### BEGIN INIT INFO
    # Provides:          ibm-websphere
    # Required-Start:    $local_fs $remote_fs $network $syslog
    # Required-Stop:     $local_fs $remote_fs $network $syslog
    # Default-Start:     2 3 4 5
    # Default-Stop:      0 1 6
    # Short-Description: Start/stop IBM WebSphere Application Server
    ### END INIT INFO
    #
    # IBM WAS	This init.d script starts the IBM WebSphere 
    #           Application Server.
    
    # modify the following line as needed to reflect any custom Java
    # installation directory
    ENV="env -i LANG=C PATH=/opt/IBM/ibm-java-x86_64_60/bin:/usr/bin:/bin"
    
    set -e
    if [ ! -d /opt/IBM/WebSphere/AppServer/bin ] ; then
    	echo "No IBM WebSphere Application Server installed"
    	exit 0
    fi
    
    . /lib/lsb/init-functions
    
    test -f /etc/default/rcS && . /etc/default/rcS
    
    startscript=/opt/IBM/WebSphere/AppServer/bin/startServer.sh
    shutscript=/opt/IBM/WebSphere/AppServer/bin/stopServer.sh
    
    case $1 in
    	start)
    		log_daemon_msg "Starting application server" "IBM WAS"
    		if $startscript ; then
    			log_end_msg 0
    		else
    			log_end_msg 1
    		fi
    	;;
    	stop)
    		log_daemon_msg "Stopping application server" "IBM WAS"
    		if $stopscript -user was-admin -password PASSWORD; then
    			log_end_msg 0
    		else
    			log_end_msg 1
    		fi
    	restart)
    		log_daemon_msg "Restarting Web server" "IBM HTTP"
    		if ($stopscript -user was-admin -password PASSWORD && $startscript)
              then
                log_end_msg 0
    		  else
                log_end_msg 1
              fi
    	;;
    	*)
    		log_success_msg "Usage: /etc/init.d/websphere {start|stop|restart}"
    		exit 1
    	;;
    esac

    下载此文件之后,执行以下步骤:

    1. 作为根用户或通过 sudo 命令,把此文件保存到系统上并把它复制到 /etc/init.d 中,把它命名为 websphere_upstart.sh
    2. 作为根用户或使用 sudo 命令,使用以下命令设置文件的可执行权限:
      chmod 755 /etc/init.d/websphere_upstart.sh
    3. 通过使用下面这样的命令,在与系统的默认运行级相关联的目录(通常是 /etc/rc2.d 目录)中创建此文件的符号链接:
      ln -s /etc/init.d/websphere_upstart.sh /etc/rc2.d/S91ibm-was
      ln -s /etc/init.d/websphere_upstart.sh /etc/rc2.d/K15ibm-was

    在下一次关闭系统时,这里创建的 K15ibm-was 符号链接会在关闭过程中自动停止 WebSphere Application Server。在下一次启动系统时,S91ibm-was 符号链接会在启动过程中自动启动 WebSphere Application Server。

    后续步骤

    恭喜!您已经安装了 WebSphere Application Server 并把它集成在系统的启动和关闭过程中。现在,可以添加自己的应用程序、定制服务器的配置等等。编写和集成 WebSphere 应用程序超出了本教程的范围。但是,下面这些信息有助于您使用 WebSphere Application Server:

    • 要想在安装 WebSphere Application Server 的系统上在浏览器中打开管理控制台,应该访问以下 URL:

      https://localhost:9043/ibm/console

      这时显示 图 12 所示的屏幕。输入 在安装过程中定义的管理用户名和密码 并单击 Login 或按回车,从而显示 WebSphere Application Server 管理控制台,见 图 14

    • 要想再次执行 First steps 控制台,使用以下命令:

      cd  /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/firststeps
      ./firststeps.sh

    结束语

    应用服务器是大多数 3 层企业 Web 系统的核心。IBM WebSphere Application Server 是当今最流行的应用服务器之一,由 IBM、许多第三方应用程序和厂商支持。您可以下载和体验 WebSphere Application Server 的试用版,在自己的环境中安装、测试和熟悉 WebSphere Application Server 是很容易的。WebSphere Application Server 为企业 Web 应用程序和服务提供一个健壮、强大、经过良好测试且具备良好支持的基础。

    展开全文
  • jdk1.8 Hotspot虚拟机参数通用配置

    千次阅读 2018-10-30 20:17:55
    下面是整理的一些通用参数的含义或配置说明,虽然这些配置网上到处都有,但笔者这是结合实际应用加以整理收集的,希望能带来参考价值,最后附上某一知名大公司JVM配置清单,以做参考。 -XX:CMSClassUnloadingEnabled...
  • OBM,ODM,OEM分别指什么

    千次阅读 2017-07-01 09:56:21
    什么是OEM?OEM(Original Equipment Manufactuce,原始设备生产商)。 是在社会化分工、专业化利益驱动下产生的,其基本含义是:按原单位(品牌单位)委托合同进行产品开发和制造,用原单位商标,由原单位销售或经营...
  • Github Mybatis深入学习之XML配置

    千次阅读 2013-11-08 16:50:44
    MyBatis的配置的灵活性也是其一大亮点,这样适合不同的配置需求,显得其有包涵有涵养。所以,这也是许多公司选择它作为持久化框架的原因。 原文地址:http://mybatis.github.io/mybatis-3/configuration.html ...
  • 随着游戏制作技术的不断发展,在经历了从2D到3D、从单机到网游、从PC游戏到移动游戏的种种演变后,玩家对于游戏质量的要求越来越高,游戏制作的难度相应地...为什么要谈游戏数据的配置和管理不知道大家是不是会和博主
  • 路由器交换器配置ospf

    千次阅读 2015-03-07 11:31:08
    路由交换OSPF协议  OSPF是开放式最短路径优先协议,是目前使用非常广泛的一个协议。开放式是各个厂商都支持。  本章目标  链路状态路由选择协议概述  OSPF开放式最短路径优先 ... 单区域OSPF配置
  • 第七章 软件配置管理

    万次阅读 2018-07-02 14:41:56
    本章内容提要软件配置管理的作用软件配置管理的相关概念建立软件配置管理环境版本控制系统集成分支管理变更管理配置审计和配置状态报告配置管理过程软件配置管理工具第一节 软件配置管理的作用星形网拓扑结构不同...
  • 七大配置策略详解

    千次阅读 2018-02-26 20:37:11
    美林投资时钟投资策略相信大家都有所耳闻,作为资产配置最为著名的模型,它具体的概念主要,以经济周期为框架,把「资产」、「行业轮动」、「经济周期四个阶段」以及「债券收益率曲线」四个因素联动起来,作为投资...
  • Hadoop概述与安装配置

    万次阅读 2019-06-21 20:00:40
    大数据介绍 大数据的由来 大数据 随着计算机技术的发展,...什么是大数据 大数据的定义 大数据无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合,需要新处理模式才能具有更强的决策力、洞察发...
  • 浅析桌面虚拟化给企业带来的价值

    万次阅读 2019-08-21 15:52:04
    当今很多企业热衷于上桌面虚拟化,什么是桌面虚拟化?桌面虚拟化能给企业带来什么价值? 针对第一个话题,首先让我们来了解一下什么是桌面虚拟化? 桌面虚拟化是将计算机的终端系统(也称作桌面)进行虚拟化,...
  • 16、nginx 错误页面配置 nginx错误页面包括404 403 500 502 503 504等页面,只需要在server中增加以下配置即可: error_page 404 403 500 502 503 504 /404.html; location = /404.html { root /usr/local/nginx/...
  • LOGBACK 配置: 用 XML

    万次阅读 2016-07-31 23:58:20
    现如今,java 开发中 都用logback来配置日志了。之前看到一篇好文章,翻译分享给大家。 原文前言当底层的日志记录框架成为一个技术瓶颈时,将无法很好记录日志。日志记录框架需要是快速的,有一个小的内存占用空间...
  • Android studio 3.0安装配置方法图文教程

    万次阅读 热门讨论 2018-01-17 12:53:58
    这篇文章主要为大家详细介绍了Android studio 3.0安装配置方法图文教程,具有一定的参考价值,感兴趣的小伙伴们可以参考一下 本文为大家分享了Android studio安装与配置,具体内容如下 1、首先下载Android ...
  • 云计算的概念和价值

    万次阅读 多人点赞 2018-05-15 22:28:03
    云计算(cloud computing)是一种按是使用量付费的模式,这种模式是可用的、便捷的、按需的网络访问,进入可配置的计算机资源共享池(资源包括网络,服务器,存储,应用软件,服务),这些资源能够被快速提供,只需要...
  • Java环境变量配置--解决“找不到或无法加载主类”

    千次阅读 热门讨论 2015-06-08 15:39:22
    JDK安装成功之后,配置好环境变量之后写了一个Helloworld测试没有问题了,但是在敲一个容器例子的时候,发生了下面的问题。  问题重现:  奇怪的是我上一个例子没有问题,这个却出了问题。在确定了...
  • MyBatis核心配置文件标签简介

    千次阅读 2018-01-25 22:56:42
    XML 映射配置文件 MyBatis的配置文件包含了影响MyBatis行为甚深的设置(settings)和属性(properties)信息。文档的顶层结果如下: configuration配置 properties属性 setting设置 typeAliases类型命名 typeHandlers...
  • 本文就是对findbugs的介绍,为了了解这个插件的使用,也是网上的介绍天花乱坠,讲的一个字就是不懂什么情况,会用才是根本,真心的想说天朝程序员就是操蛋,哈哈哈哈哈哈哈哈
  • Mapper XML文件 配置详解

    万次阅读 多人点赞 2018-02-25 21:17:02
    MyBatis 的真正强大在于它的映射语句,也是它的魔力所在。由于它的异常强大,映射器的 XML 文件就...SQL 映射文件有很少的几个顶级元素(按照它们应该被定义的顺序):cache – 给定命名空间的缓存配置。cache-ref...
  • Simulink代码生成: Storage Class配置

    千次阅读 多人点赞 2020-05-31 22:22:35
    之前一篇博客《Simulink代码生成: 信号线、参数配置》中,提及了一部分Storage Class(存储类型)的配置及其代码。本文更加详细地研究Storage Class中各个选项的含义以及生成的代码。 文章目录1 示例模型2 Storage ...
  • 可以为运行在同一物理机器上的各个网站配不同的 IP 和端口, 也可让多个网站拥有不同的域名. Apache 是世界上使用最广的 Web 服务器, 从 1.1 版开始支持虚拟主机. 本文将讲解在不同服务器 (Redhat Enterprise ...
  • 互联网时代运维价值

    千次阅读 2016-08-19 00:47:40
    互联网时代运维价值 最近跟朋友聊起工作,我说干运维的,他略显诧异的说这行业感觉有点low啊,好多专科技校、蓝翔电脑培训出来的孩子都搞这个。嗯,这朋友倒是蛮心直口快的,只好无奈一笑,不以为意。后来一...
  • Mysql5.6配置文件详解

    千次阅读 2016-04-26 23:36:35
    以下是翻译后的my.cnf配置文件说明: [mysqld]   #*******Server******   #******server start related   #user= #运行mysqld服务器的用户名user_name或数字...
  • RIP配置(6)——RIP与不连续子网

    千次阅读 2019-05-28 20:34:22
    原理简述: 连续子网:所相连的子网属于同一主网; 不连续子网:相同主网下的子网被另一主网分隔开。 ...RIP会在主网边界上进行自动汇总,当发生汇总时,汇总的子网路由在...例如某个路由器上配置了多个网段,...
  • 在美团的价值观中,“以客户为中心”被放在一个非常重要的位置,所以我们对服务出现故障越来越不能容忍。特别是目前公司业务正在高速增长阶段,每一次故障对公司来说都是一笔非常不小的损失。而整个IT基础设施非常...
  • Oracle Coherence中文教程三:配置

    千次阅读 2015-02-09 11:12:18
    配置 本章介绍每一个都散发着连贯性和应用和解决方案的详细介绍了如何创建自己的连贯性配置时覆盖这些文件的默认配置文件。 3.1默认的配置文件概述 Coherence 分布包括默认的XML配置文件内COHERENCE_HOME\ ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 69,339
精华内容 27,735
关键字:

价值配置是指的什么