配置管理最佳实践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可扩展性和开放的API 18

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不可变的版本ID 28

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 Maven 34

2.5.3 Maven与Ant 34

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控制框架的COBIT 155

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 COBIT 173

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

14.6.3 itSMF的ITIL框架 183

14.6.4软件工程知识体系 189

14.6.5开放统一过程（OpenUP） 190

14.6.6敏捷／SCRUM 190

结论 191