持续交付读书笔记

Advocates：
http://martinfowler.com/delivery.html http://build-doctor.com/

Build Tools Reference：

Maven + Go
http://blog.orfjackal.net/2012/08/continuous-delivery-with-maven-and-go.html
Go Download
http://www.go.cd/download/
Problems with Make
http://blog.plover.com/2008/03/28/
Build Tools 问题:

Make:平台相关

Ant: 写XML太累，难以维护，统计每个步骤的时间还有测试通过率等指标需要自己写插件

Maven: 项目目录结构和流程必须符合其规范，自动升级，难以固定住依赖库版本，plugin不好写

Buildr: Apache Buildr 是对Ant和Maven的升级

Scons: 对make的升级，用到python语言

Rake:通用构建工具，用到ruby语言，rubygems

打包：

尽量使用操作系统自带的打包工具

--Good advice；同意。本人最近经历过，在windows上使用NSIS脚本，结果发现NSIS默认不支持超过1024个字符的字符串（原先不知道有这个限制），导致在环境变量path超过1024个字符时被清空，在装了一大堆软件的机器上会发生，也不是经常发生，一旦发生，恢复起来就不好恢复。

--看来是时候把NSIS换为windows系统自带的打包工具了。

Jean-Paul Boodhoo’s blog
http://blog.developwithpassion.com/categories/continuous-integration/ (Current)
http://codebetter.com/jpboodhoo/ (Previous blogs)

Maven标准目录结构



向远程机器部署的三种方法：（P161）

第一种：写一个脚本，分别登录各机器，执行有关命令

(Unix: scp, rsync; Windows: Psexec, Powershell)

(工具：Fabric, Func, and Capistrano）

(很难处理错误情况，因此尽量避免)

第二种：写一个本地脚本，但是有远程的Agent

（次强大，持续集成服务器（带有agent模型），

(很难处理错误情况，因此尽量避免)

第三种：打包，用基础设施管理工具或者部署工具部署

（最强大，可以同时完成部署和基础设施管理）

(可以处理错误情况，首选)

部署工具：

ControlTier

BMC BladeLogic

基础设施管理工具：

Marionette Collective

CfEngine

Puppet

部署的层次 P162

硬件

操作系统、操作系统的配置

中间件、中间件的配置

应用、应用的配置

基础设施的冒烟测试

配置管理最佳实践 Bob Aiello

http://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B00EHLQWGY http://cmbestpractices.com/
只使用相对路径

绝对路径另行存放，不要混在一起

Unix应遵循Filesystem Hierarchy Standard (FHS)

应关注整体指标，最重要的是：cycle time（从创意到交付用户的时间）

而不是单独关注某个指标：比如bug率，因为过分追求一个指标不利于整体的提高。

P166

用md5码，版本号标记一个二进制，存入数据库

不要把二进制文件放进版本管理

把生成的东西放入共享文件系统，

可以使用Maven, Ivy, Nexus

Nexus私服可解决使用maven的机器上不了internet问题
http://www.sonatype.org/nexus/go/
如果某测试失败了，做个标记，等跑完其他的测试再整体标记failed，这样可以尽量多收集信息。否则浪费时间。

unit test anti-patterns
http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/
单元测试

执行要快

至少80%代码覆盖率

不要调用中间件（数据库、消息机制）

测试消息时，两步分开，一步测发消息，一步测收到消息的响应

Stubbing（一般在组件或子系统）：用模拟的替代真实的

Mocking（可以少写代码，推荐使用）

时间相关的放入独立的类