配置管理最佳实践PDF|Epub|txt|kindle电子书版本网盘下载

配置管理最佳实践PDF格式电子书版下载

注意：本站所有压缩包均有解压码： 点击下载压缩包解压工具

第Ⅰ部分 配置管理核心实践1

第1章 源代码管理3

术语和源代码管理4

源代码管理的目标5

源代码管理的原则5

1.1为什么源代码管理如此重要6

1.2从哪里开始7

1.3源代码管理核心概念8

1.3.1建立基线和时间机器8

1.3.2保留与非保留签出9

1.3.3沙箱和工作空间10

1.3.4变体管理10

1.3.5复制分支与增量分支11

1.3.6如何处理缺陷修复11

1.3.7流12

1.3.8合并13

1.3.9变更集14

1.4权限和需求跟踪14

1.5管理全球分布式开发团队15

1.6工具的选择16

1.6.1开源软件与商业软件17

1.6.2产品成熟度和供应商承诺18

1.6.3可扩展性和开放的API18

1.6.4不要过度工程化源代码管理19

1.7认识质量成本和总拥有成本19

1.8培训20

1.9建立使用模型21

1.10实施时间和风险22

1.11建立支持过程22

1.12高级特性和授权高级用户23

结论23

第2章 构建工程25

构建工程的目标26

构建工程的原则26

2.1为什么构建工程如此重要27

2.2从哪里开始27

2.3构建工程的核心概念28

2.3.1版本1D和标记可执行文件28

2.3.2不可变的版本ID28

2.3.3打上版本标记或者标签28

2.3.4管理编译依赖29

2.3.5独立构建29

2.4建立构建职能的注意事项30

2.4.1推广独立构建30

2.4.2过度工程化构建30

2.4.3保持正直和诚实31

2.4.4隶属研发部门引起的利益冲突32

2.4.5组织结构的选择32

2.5构建工具评估和选择33

2.5.1 Apache Ant进入构建舞台33

2.5.2 Maven34

2.5.3 Maven与Ant34

2.5.4使用Ant生成复杂构建34

2.5.5持续集成35

2.5.6持续集成系统35

2.5.7集成开发环境36

2.5.8静态代码分析36

2.5.9构建框架36

2.5.10构建工具的选择36

2.5.11对比优缺点达成一致37

2.6质量和培训成本37

2.7把构建做得更好37

2.7.1鲍勃的构建秘方38

2.7.2测试驱动的构建38

2.7.3信任但仍要核查38

2.7.4飞机的驾驶舱38

2.8构建工程师的角色39

2.8.1了解构建的项目39

2.8.2与开发人员合作40

2.8.3招募新人40

2.9架构是构建的基础40

2.10建立构建过程41

2.11持续集成与每日构建41

2.12构建工程的前景42

结论42

第3章 环境配置43

环境配置控制的目标44

环境配置控制的原则44

3.1为什么环境配置如此重要45

3.2从哪里着手45

3.3支持代码提升45

3.4管理配置46

3.4.1使用的是哪个数据库46

3.4.2那笔交易发生了吗46

3.4.3少用几个符号47

3.4.4集中分配环境变量48

3.5建立配置管理数据库的实际方法48

3.5.1识别和控制48

3.5.2理解环境配置49

3.6依赖于环境配置的变更控制49

3.7减少控制49

3.8管理环境50

3.9环境配置的未来50

结论51

第4章 变更控制53

变更控制的目标54

变更控制的原则54

4.1变更控制为何如此重要54

4.2变更控制从何做起55

4.3变更控制的七种类型55

4.3.1优先级55

4.3.2把关控制56

4.3.3配置控制56

4.3.4变更咨询委员会57

4.3.5紧急变更控制57

4.3.6过程工程57

4.3.7高级管理人员监督57

4.4建立变更控制58

4.5变更控制实例58

4.5.1 29分钟变更控制会议59

4.5.2投资银行变更控制59

4.5.3贸易公司的变更控制60

4.5.4伪造批准61

4.6时刻不要忘记风险61

4.7通过变更控制推动配置管理流程62

4.8进入／退出标准62

4.9事后审查63

4.10自我评估63

结论64

第5章 发布管理65

发布管理的目标66

发布管理的原则66

5.1为什么发布管理如此重要66

5.2从哪里开始67

5.3发布管理的概念和实践67

5.3.1可行的打包策略67

5.3.2发布包版本识别68

5.3.3发布版本的材料清单68

5.3.4不可变ID意味着什么68

5.4发布管理人类工程学68

5.4.1避免人为错误69

5.4.2了解技术69

5.4.3构建工程工具69

5.4.4避免人为错误70

5.4.5三步走70

5.4.6太多可变部分70

5.5发布管理的协调职能71

5.5.1沟通发布状态71

5.5.2不要忘记发布日程表71

5.5.3发布管理和配置控制71

5.6需求跟踪71

5.7将发布管理提升到新的层次72

5.7.1使用加密技术签名代码72

5.7.2操作系统对发布管理的支持72

5.7.3改善你的发布管理过程73

结论73

第6章 部署75

部署的目标76

部署的原则76

6.1为什么部署很重要76

6.2从哪里开始77

6.3实践和实例77

6.3.1发布中转区77

6.3.2脚本控制发布过程78

6.3.3部署框架78

6.3.4如果鲍勃犯了个错误怎么办79

6.3.5细说存储库79

6.3.6审计发行版本79

6.4进行配置审计80

6.5不要忘记冒烟测试80

6.6小失误导致大问题81

6.7沟通计划81

6.8部署应当授权82

6.9信任也要核查82

6.10改进部署过程82

结论82

第Ⅱ部分 架构和硬件配置管理83

第7章 为配置管理设计应用程序架构85

为配置管理设计应用程序架构的目标86

7.1为什么架构很重要86

7.2从哪里开始87

7.3配置管理如何促进良好的架构87

7.4架构师可以从测试人员那里学到什么87

7.5配置管理驱动开发88

7.6应对不断变化的架构89

7.7使用源代码管理促进架构89

7.8培训是关键89

7.9作为服务的源代码管理90

7.10作为服务的构建工程90

结论90

第8章 硬件配置管理91

硬件配置管理的目标92

8.1为什么硬件配置管理的重要92

8.2从哪里开始92

8.3当无法版本控制电路芯片时93

8.3.1配置项的任何其他名称93

8.3.2设计规范的版本控制93

8.4不要忘记接口93

8.5了解依赖关系94

8.6可追溯性94

8.7部署变更到固件94

8.8硬件配置管理的未来94

结论95

第Ⅲ部分 配置管理中人的因素97

第9章 合理精简过程99

合理精简配置管理过程的目标100

9.1为什么合理精简配置管理过程很重要101

9.2从哪里开始101

9.3繁琐的过程只会成为障碍102

9.4软件过程改进网络和推广能力成熟度模型102

9.5正在消失的烦琐过程103

9.5.1敏捷开发过程就是有用103

9.5.2开放统一过程104

9.5.3变得精益104

9.5.4希望能够激励人仔细了解精益软件开发的一个非常简短的描述104

9.6过程太少的危险105

9.7恰好够用的过程改进105

9.8不要过度工程化配置管理105

9.9不要忘了技术106

9.10测试自己的过程106

9.11过程咨询106

9.12创建一个可持续发展的结构107

结论107

第10章 克服变革的阻力109

克服变革阻力的目的110

10.1为什么克服变革阻力很重要111

10.2从哪里开始111

10.3过程与企业文化相匹配111

10.4心理学和计算机程序设计相结合112

10.5从内部进行过程改进113

10.6选择首先要解决的问题114

10.7培养团队协作114

10.8为什么优秀的开发人员反对过程改进115

10.9程序公正115

10.10听取每个人的意见115

10.11展现领导能力116

10.12实施过程改进的人本身可能会成为问题116

10.13过程和技术培训相结合116

10.14倾听节奏117

10.15过程需要得到测试118

10.16婴儿般的步伐和过程改进119

10.17推销过程改进119

10.18什么是我需要的119

10.19作为服务的过程改进120

10.20过程改进的游击战术120

结论121

第11章 个性与配置管理：一位心理学家眼中的工作场所123

了解个性的目的：对我而言有何用处124

11.1配置管理专业人员的个性处理125

11.2配置管理专家从个性的角度所要考虑的因素128

11.2.1沟通风格128

11.2.2男人和女人使用和解释语言或有差异128

11.2.3有效的协商129

11.2.4信息的核实129

11.2.5信息处理的偏好130

11.2.6工作中的出生顺序131

11.2.7作为领导者的长子131

11.2.8作为妥协者的老二131

11.2.9作为发起者的老么132

11.2.10独生子132

11.2.11做你自己133

11.3心理学在工作场所的应用133

11.3.1有效的团队协作从家庭开始133

11.3.2排球或有效协作134

11.3.3把构建工程师和测试人员嵌入开发团队中134

11.3.4黑盒、白盒以及灰盒测试的对比134

11.3.5破坏性的小组形态135

11.3.6适合配置管理和质量检测的位置135

11.4家庭动态135

11.5工作场所的文化和个性136

11.5.1个性和结构137

11.5.2我们已经发明了所有的好点子137

11.5.3我行我素，不守规矩138

11.5.4在保持列车运行的同时保持有效的监督138

11.5.5成功的配方139

11.5.6注意事项139

结论139

第12章 从错误中吸取教训141

从错误中吸取教训的目的142

12.1从错误中吸取教训的重要性142

12.2从错误中吸取教训的第一步142

12.3明白我们的错误142

12.4我所犯的错误143

12.4.1缺乏大局观143

12.4.2编写发布自动化脚本是一项很有挑战性的工作144

12.4.3关于良好的进程会自我运行的思考144

12.4.4未能取得共识145

12.4.5未能在配置管理上展现领导能力145

12.4.6成为问题的一部分145

12.4.7忘记向他人寻求帮助146

12.5把错误变成教训146

12.5.1明确知道如何做才能完成工作146

12.5.2获得所需要的培训146

12.6他人常犯的错误147

12.6.1象牙塔147

12.6.2没能提高自己的技术和动手能力147

12.6.3缺乏诚实和坦然的态度147

结论148

第Ⅳ部分 合规、行业标准和框架149

第13章 建立IT控制及合规性151

建立IT控制及合规性的目标152

13.1为什么IT控制及合规性很重要153

13.2建立IT控制及合规性的第一步153

13.3理解IT控制及合规性154

13.3.1 2002年发布的“萨班斯一奥克斯利法案”154

13.3.2内部控制的管理评估154

13.3.3发起机构委员会155

13.3.4用于IT控制框架的COBIT155

13.3.5核实并汇报管理层所做出的评估155

13.3.6 1996年发布的健康保险隐私及责任法案156

13.3.7当美国审计署来敲你门的时候156

13.3.8审计结果157

13.3.9美国审计署关于国家档案记录管理局的配置管理实践的报告158

13.3.10美国电子文件档案馆的配置管理规划158

13.3.11有待改善的领域159

13.3.12了解审计结果159

13.3.13美国金融管理局159

13.4必不可少的合规性要求160

13.4.1为版本发布提供可追溯的需求160

13.4.2控制生产分离160

13.5支持配置管理最佳实践的道德观点161

13.6通过合规性来提高工作质量和效率161

13.7进行配置管理评估162

13.7.1评估的第一步162

13.7.2无论出现多么糟糕的情况也要先留心去听163

结论164

第14章 行业标准和框架165

使用行业标准和框架的目标166

14.1为什么标准和框架很重要166

14.2以IT控制及合规性为最佳实践的第一步166

14.3必知的专业术语167

14.3.1配置项167

14.3.2配置标识167

14.3.3配置控制168

14.3.4接口控制168

14.3.5配置状态统计168

14.3.6配置审计169

14.3.7分包商／供应商的管理手段169

14.3.8符合规范与违规170

14.4将这些条款应用在标准和框架里170

14.5行业标准170

14.5.1 IEEE 828——标准软件配置管理方案171

14.5.2 ISO 10007质量管理体系——配置管理的指导方针172

14.5.3 ANSI/ITAA EIA-649-A——配置管理的国家统一标准172

14.5.4 ISO／IEC／IEEE 12207和15288标准173

14.6行业框架173

14.6.1 ISACA COBIT173

14.6.2能力成熟度模型／能力成熟度模型集成182

14.6.3 itSMF的ITIL框架183

14.6.4软件工程知识体系189

14.6.5开放统一过程（OpenUP）190

14.6.6敏捷／SCRUM190

结论191