CI 环境权限控制的几个目标:
能够与域账号集成能够单独针对每个项目设定用户权限, 即不同的员工对不同的项目可以有不同的权限能够单独设置是否能看到源代码的权限能够单独设置浏览查看项目构建信息和编辑修改运行项目构建信息, 即分开只读和修改权限1. 与域账号集成Jenkins 支持多种用户管理策略, 其中包括 LDAP 集成, 如下图:

2. 项目级别的权限控制Jenkins 支持针对单个项目进行不同的权限控制. 具体操作如下:
首先进入”Manage Jenkins” -> “Configure Global Security”, 点选”Project-based Matrix Authorization Strategy”, 如下图:

其次, 针对每个需要配置的项目, 进入其对应的 Job 配置页面, 勾选”Enable project-based security”, 如下图:

然后就可以挑选能访问该项目的用户, 并配置权限, 如上图中的 rcp 和 anonymous 用户.
3. 单独设置是否能看到源代码的权限在 Jenkins 中, 源代码及其所在目录,...阅读全文

Master 能够信任 agent
puppet 的 master 和 agent 之间通过证书服务器签发的证书来建立信任. 最简单的颁发和认证证书的方式如下:
agent 第一次连接 master 时,会生成证书请求, 缺省以自己的主机名作为标识; 在 master 机器上, 可以用 puppet cert list --all 来查看在 master 机器上, 运行 puppet cert sign agent_host_name_cert_request在 agent 机器上重新运行 puppet agent 即可建立连接.
运行Puppet master 能够将最新的配置信息下发给 agent, 需要满足以下几个条件:
master 需要知道把哪些配置推给 agentagent 在该配置所允许的主机列表中Master 需要知道把哪些配置推给 agent
在3.0.1版本中, puppet 使用 environment 的概念来组织配置信息. 一个 environment 可以包含多个 module.
需要做两件事来匹配 agent 和特定的配置:
agent ...阅读全文

2014-10-09
复杂系统 I: 自组织和全局优化的代价自组织的代价什么时候自组织, 什么时候集权控制?
大量自组织的个体会形成复杂系统, 更高级的智能和创新会从中涌现出来. 创新是自组织系统的强项. 但这种强项是以冗余和低效为代价的.
这意味着在需要高效的场景下, 我们不应该放任自组织, 比如紧急事故逃生现场, 如果每个人都自行其是, 依赖环境的反馈最终达成一致, 后果是灾难性的. 此时中央集权统一指挥效率更高.
所以什么时候自组织合适? 大量个体, 创新比效率更重要的场合. 什么时候集权控制? 少数个体, 效率比创新更重要的场合. 
全局优化的代价什么时候全局优化, 什么时候局部优化或不优化?
全局优化会带来效率的提升, 一个典型的例子是全球化, 很多大企业如沃尔玛, 戴尔等都建立了全球供应链, 极大的提升了效率和降低了成本. 但这种效率的提升是以脆弱性为代价的. 任何一个环节出了问题, 都会影响到全局.
鼓吹全球化的代表性畅销读物是<<世界是平的>>, 里面有沃尔玛戴尔等详细的例子. 其作者是纽约时报专栏记者, 三次普利策奖获得者托马斯•弗里德曼（Tho...阅读全文

2015-06-01
当谈论覆盖率时我们在谈什么代码覆盖率 vs. 测试覆盖率代码覆盖率通常指跑完测试后, 由工具自动统计的在跑测试的过程中被测代码的覆盖率, 细分的话包括语句覆盖率, 分支覆盖率, 函数覆盖率等. 由于代码覆盖率可由工具自动产生, 采集成本非常低, 而又比较直观, 所以历来受到开发团队及管理者的欢迎, 有的组织甚至将其作为 KPI 指标之一.
然而围绕着代码覆盖率, 有很多有趣的事情, 尤其是将其作为 KPI 的时候. 你会发现, 长期在低位徘徊的代码覆盖率, 突然之间会有一个比较大的提升. 究其原因, 是开发团队在短时间内加了”测试”. “测试”是打引号的, 因为当我们近距离观察这些”测试”的时候, 会发现通常是调用了某个高层的入口函数, 因而牵出很多底层函数, 覆盖率就上去了, 然而, 没有一个断言(assertion), 或者是区区几个断言. 也就是说, 把产品跑了一遍, 但没有判断其行为是否符合预期, 而代码覆盖率突然就达标了.
尽管对于追求自我改进的团队来说, 不会这么掩耳盗铃, 代码覆盖率依然是有价值的反馈指标, 但这从侧面说明了代码覆盖率并...阅读全文

2015-05-04
Scrum: 死马? (一) 三种角色Scrum失败的原因有很多. 很普遍的一个原因是, 忽视其众多前提而仅仅是把现在的基层开发组织按照Scrum要求的那三种角色改一下, 就算是上马了, 很快Scrum也就像它的音译那样, 变成死马了, 仅留一身马皮. 我们来看一下为什么仅仅把基层开发组织改组为Scrum团队是不工作的.
角色一, PO: PO的任职资格在我所见过的Scrum团队中, 绝大部分PO是不具备PO的资格的. 不是说能力, 而是资格. PO从职责上讲, 拥有Product Backlog, 负责决定哪些功能进, 哪些功能不进, 优先级是什么, 换句话说, PO负责产品的方向. Product Owner这个词从字面上也赋予了PO这种职责. 但与这种职责相伴的是对应的资格, 你必须有资格能够负责产品的方向, 你才能负责产品的方向. 那么通常都是什么样的人有资格负责产品的方向呢?
如果你是一个定制化开发项目, 企业应用, 毫无疑问, 是客户才有资格负责产品的方向如果你是一个产品项目, 面向多个潜在客户, 那么你们组织里面谁对产品的成败负首要责任...阅读全文