讨论点实质性的东西吧-Tools Team的开发管理

[刘海阳]

摘要：

    我想利用敏捷的最佳实践提升所在Tools Team的开发质量，但是Tools开发的特点是：短周期，多项目，多语言，多环境，多需求来源，还有support类工作。所以做起来不太得心应手。

Team背景：

• 某互联网公司运维部门的Tools Team。
• 主要职责是给通过开发工具支持运维部门。现在阶段的主要工作：Zabbix监控/CMDB建模和实现/SSO部署/生产日志分析/Release&Build自动化等。
• 5人团队，我是新加入的，Java开发背景，其他同事是SA背景的开发。
• 开发语言主要是Python，但是为了完成需求，会用到各种语言实现的开源产品。大部分开源产品我们需要自己fix bug以及二次开发。

一些显而易见的问题：

1. 代码管理混乱
• 没有版本控制
• 历史原因：Java开发中Eclipse IDE搞定一切。现在面对不同的需求要用不同的语言在不同的OS和不同的工具上开发，例如Zabbix的bug fix就在linux上用VIM开发，CMDB前端的JS又是在window上开发的，每个人的开发习惯也不同，有人喜欢IDE，有人只用VIM。代码很难随时/方便的check in。
2. 上线代码没有review
• 没有版本控制的支持，想review也困难。
3. 没有质量管理
• Tools独立于PD，没有QA资源。代码质量只能自己保证。
4. 没有持续集成
• 其实这是一个伪问题，虽然这里没人认为CI是必须的，但是我实在是觉得没有CI真的是个问题。

每个问题或多或少和开发周期紧张有关系，其实每家公司情况都相同，这里就不提了。

所以，我希望和同学们讨论一下：

1. 在非IDE开发中怎么做版本控制最方便？
1. 强大的IDE+Plugin可以搞定一切，但是用VIM的同事怎么办？CLI自己搞定？
2. 用SVN/GIT简单，但是设计一个适用于多语言的code repository目录结构就麻烦了，有经验的同学共享一下。
2. 有没有必要推广TDD或者对单元测试有所要求吗？
1. 个人TDD观点：我个人是TDD的拥护者和实践者。但是，我认为TDD是无法强制推广的，因为TDD是程序员的个人思考方式和习惯。
2. 很多团队对代码有测试覆盖率要求，我认为这样是幼稚的。但是，我找不到其他更好的办法。所以，我纠结。
3. Shell脚本能单元测试吗？需要单元测试吗？
• 这方面不我不熟悉，刚才问了一下写Shell脚本的同事：Shell脚本能单元测试吗？同事乐了，Shell需要单元测试吗？
4. 同在Tools Team的同学分享点开发管理经验吧
• 在了解了自己Team的环境后，我觉得Scrum的一套在这里行不通。
• 我不可能为了某一个大点的项目组建一个Scrum Team。 大家都是跨项目工作的，干扰太大。
• 想过把所有来路的需求都放入backlog维护，但是我最终放弃了这个想法。我们要频繁交付，Scrum以周为单位的周期太漫长了。
• 我想借鉴敏捷开发的最佳实践，但是我又不想直接照搬几个best practice了事。
• 最终目的是：通过改进过程管理来达到提升Team整体开发能力的目的。

写邮件的同时也review了一遍自己的问题，似乎一切罪恶的根源都在于Tools Team这种零散式的开发。以前一直做Java项目/产品开发，整齐习惯了。

怎样在现在的环境下保持开发和代码的低熵有序，开始改进之前，真需要认真思考规划一下。

面向开发细节，大家有经验就分享下，high level的东西就别扯了，看着累。

谢谢

刘海阳

[Joseph Tseng]

写得好！ 提这个问题有时候比空泛的结论更有价值~ 先mark。

2012/3/20 刘海阳 <liuha...@gmail.com>

刘海阳

--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina

--
Joseph Tseng

[Steven Mak]

svn 或者 git 都有 cli 的使用，慣用 vim 的同事都應該很易上手。

sh 腳本的 TDD 我未試過，shunit2 可以試試看： http://code.google.com/p/shunit2/

如果覺得每周作單位太長的話，每天可以吧？

On Mar 20, 12:10 pm, 刘海阳 <liuhaiy...@gmail.com> wrote:
> 摘要：
> 我想利用敏捷的最佳实践提升所在Tools Team的开发质量，但是Tools开发的特点是：*短周期*，*多项目*，*多语言*，*多环境*，*
> 多需求来源，还有support类工作*。所以做起来不太得心应手。
>
> Team背景：
>
> - 某互联网公司运维部门的Tools Team。
> -
> 主要职责是给通过开发工具支持运维部门。现在阶段的主要工作：Zabbix监控/CMDB建模和实现/SSO部署/生产日志分析/Release&Build自动化等。
> - 5人团队，我是新加入的，Java开发背景，其他同事是SA背景的开发。
> - 开发语言主要是Python，但是为了完成需求，会用到各种语言实现的开源产品。大部分开源产品我们需要自己fix bug以及二次开发。
>
> 一些显而易见的问题：
>
> 1. 代码管理混乱
> - 没有版本控制
> - 历史原因：Java开发中Eclipse

> IDE搞定一切。现在面对不同的需求要用不同的语言在不同的OS和不同的工具上开发，例如Zabbix的bug
> fix就在linux上用VIM开发，CMDB前端的JS又是在window上开发的，每个人的开发习惯也不同，有人喜欢IDE，有人只用VIM。代码很难随时/方便的check
> in。

> 2. 上线代码没有review
> - 没有版本控制的支持，想review也困难。
> 3. 没有质量管理
> - Tools独立于PD，没有QA资源。代码质量只能自己保证。
> 4. 没有持续集成
> - 其实这是一个伪问题，虽然这里没人认为CI是必须的，但是我实在是觉得没有CI真的是个问题。

>
> 每个问题或多或少和开发周期紧张有关系，其实每家公司情况都相同，这里就不提了。
>
> 所以，我希望和同学们讨论一下：
>

> 1. 在*非IDE*开发中怎么做版本控制最方便？
> 1. 强大的IDE+Plugin可以搞定一切，但是用VIM的同事怎么办？CLI自己搞定？
> 2. 用SVN/GIT简单，但是设计一个适用于*多语言*的code repository*目录结构*就麻烦了，有经验的同学共享一下。
> 2. *有没有必要推广TDD或者对单元测试有所要求吗？*
> 1. 个人TDD观点：我个人是TDD的拥护者和实践者。但是，*我认为TDD是无法强制推广的，*因为TDD是程序员的个人思考方式和习惯。
> 2. 很多团队对代码有测试覆盖率要求，我认为这样是幼稚的。*但是，我找不到其他更好的办法。*所以，我纠结。
> 3. *Shell脚本能单元测试吗？需要单元测试吗？*
> - 这方面不我不熟悉，刚才问了一下写Shell脚本的同事：Shell脚本能单元测试吗？同事乐了，Shell需要单元测试吗？
> 4. 同在Tools Team的同学分享点*开发管理*经验吧
> - 在了解了自己Team的环境后，我觉得*Scrum*的一套在这里*行不通*。
> - 我不可能为了某一个大点的项目组建一个Scrum Team。 大家都是跨项目工作的，干扰太大。
> - 想过把所有来路的需求都放入backlog维护，但是我最终放弃了这个想法。我们要频繁交付，Scrum以周为单位的周期太漫长了。
> - 我想借鉴敏捷开发的最佳实践，但是我又不想直接照搬几个best practice了事。
> - 最终目的是：通过改进过程管理来达到提升Team整体开发能力的目的。
>
> 写邮件的同时也review了一遍自己的问题，似乎一切罪恶的根源都在于Tools Team这种*零散式*

> 的开发。以前一直做Java项目/产品开发，整齐习惯了。
> 怎样在现在的环境下保持开发和代码的低熵有序，开始改进之前，真需要认真思考规划一下。
>

> *面向开发细节*，大家有经验就分享下，high level的东西就别扯了，看着累。
>
> 谢谢
> 刘海阳

[Liang Qiao]

shunit有公司在用，但用它的挑战与其它语言的unittest一样，即：写出来的shell script要有良好的可测性，比如符合单一职责原则等等。

另外，如果还没有用版本控制工具，可以直接选择git了。

关于repository的组织，不知详情，所以只能是常见的一些建议了，如根据相关性、变化频率等等组织。

关于团队组织的话，建议分成service support和service development两种职责，人员可以轮岗。比如每周有一人做support.

乔梁（Qiao Liang）

Blog: http://blog.csdn.net/tony1130

2012/3/20 Steven Mak <stev...@gmail.com>

>
> 谢谢
> 刘海阳

[陈之过]

我觉得,得从敏捷的思想出发.那么敏捷是什么思想呢,就是去掉浪费(当然应该有的东西必须得保留),这时候就需要认定什么东西是重要的,这个不必说,什么宣言,原则都写的很清楚了,那么怎样应用最佳实践呢,我觉得这几个最佳实践要有,比如版本控制\tdd\持续集成,但这都不是死的,只要团队认为合理和足够就ok了,这方面也不是一蹴而就的,需要持续的改进.下面具体说一下我的观点:

版本控制:干嘛非得统一呢,不同类型的代码,结构本来就是不同的,只要团队内部认可就行了

tdd:这个问题太......shell就不能tdd了?当初junit也只不过用了几个小时就完成了第一个版本,shell更灵活,即使没有框架,搞一个简单的,我觉得用不了多长时间.我觉得这东西不用追求多么强大和完整,简单灵活就足够了.

持续集成:这个太重要了,这个建设也不是一步完成了,慢慢来吧

迭代:这个具体如何进行,就看项目规模了,周期本来就应该是灵活控制的,也许2个小时就是一次迭代,但是迭代的各个过程应该是比较全面和完整的(这里的完整并不是绝对的).

[张克强]

针对“ 有没有必要推广TDD或者对单元测试有所要求吗？ ”

提议 分析现有软件的已经发生的问题或缺陷，看看数量和严重程度是否可以忍受？是在什么阶段注入的？可以在什么阶段检出？ 

如果有了TDD或者单元测试，能够起到什么作用？
描绘TDD/单元测试的美景 很难令人信服， 反过来 用能够承受多大的“痛苦”来判断 是否采用TDD或单元测试

刘海阳

--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina

--
张克强

blog: 从高效过程到卓越结果

weibo: http://weibo.com/zhangkeqiang 

[刘海阳]

同学们的回复很有价值。 改进是个持续长久的的过程 ，不可能一蹴而就。小步前进，在行进中开火吧。 :D

[陈之过]

楼主的总结能力很强啊!

另外,克强同学说的tdd的"痛苦",我不是很理解.

[张克强]

我说的不是TDD的痛苦，是不搞TDD或单元测试情况下的“痛苦”---从实际反馈的缺陷或抱怨当中来分析痛苦程度和原因

如果痛苦还可以承受，那就不足于说服同事们开展TDD或单元测试。
如果痛苦不愿意承受，而且原因确实与TDD或单元测试相关，那么就能有理由来说服同事们尝试TDD或单元测试。

[胡凯]

痛不痛苦，反正都是8小时（或者10/12小时）， bug不bug我都领这么多薪水。

TDD是一种价值观。

2012/3/21 张克强 <zhangk...@gmail.com>

--
All Infomation: http://iamhukai.info
Twitter:  http://twitter.com/iamhukai
Blog:  http://iamhukai.com

[刘海阳]

赞同。所以我认为TDD是无法自上而下强制推广的。

[Shen Siwei]

记得<<Pragmatic Programmer>>  里强调的非常清楚：

1.  必须版本控制 。否则你的代码就会被猫吃了。。。
2.  命令行 是 基础中的基础  。  而且用多了 比 IDE形式的 工具要舒服很多。
3.  测试驱动开发很重要。  它是持续集成的基础。 而且让人感觉更轻松。

[泥泥]

我们这边也会有些小过程工具方面的开发，比如围绕hudson这边做一些插件，工具很杂，用php做一些开源项目管理系统的二次开发，或者python做一些文件版本检查工具、windows批处理等等。楼主说的那些更复杂的业务数据收集分析度量决策等工作我们有专门的后台系统开发团队，需要一定程度的产品框架架构。

不过我们做的技术难度和规模应该没有LZ的多

说说我的意见

1. 在非IDE开发中怎么做版本控制最方便？（把目标文件夹放到SVN目录，做个自动脚本，监控文件夹，定时识别，一旦发现文件有变化，就自动submit一下，无论用啥工具编辑的，都可以如此做）
2. 有没有必要推广TDD或者对单元测试有所要求吗？（我们目前没有做到这个，因为工作量不算太多，技术压力也不算大，把任务管理做好就够了）
3. Shell脚本能单元测试吗？需要单元测试吗？（代码不多，复杂度不高，我们这边黑盒测试足够了）
4. 同在Tools Team的同学分享点开发管理经验吧

• 在了解了自己Team的环境后，我觉得Scrum的一套在这里行不通。（scrum和文化有关，和技术无关，LZ说的行不通应该也有文化的关系）
• 我不可能为了某一个大点的项目组建一个Scrum Team。 大家都是跨项目工作的，干扰太大。
• 想过把所有来路的需求都放入backlog维护，但是我最终放弃了这个想法。我们要频繁交付，Scrum以周为单位的周期太漫长了。（我这边是通过Todolist来解决的，记录下任务项，而不设置Backlog，不过我们后台团队是用Scrum的，他们用Sprint来规划每两周的重点任务。）
• 我想借鉴敏捷开发的最佳实践，但是我又不想直接照搬几个best practice了事。（借鉴本来就不是照搬啊，前半句和后半句没有冲突）
• 最终目的是：通过改进过程管理来达到提升Team整体开发能力的目的。（具体来说，过程改进提高的是信息流转效率，以及信息完整性，有的企业希望通过过程改进能实现更安全的信息流，这个也可以有。看你的目标能不能契合上头更高的目标了）

[陈之过]

> 在非IDE开发中怎么做版本控制最方便？（把目标文件夹放到SVN目录，做个自动脚本，监控文件夹，定时识别，一旦发现文件有变化，就自动submit一下，无论用啥工具编辑的，都可以如此做）

我觉得完全没有必要这样做!

> Shell脚本能单元测试吗？需要单元测试吗？（代码不多，复杂度不高，我们这边黑盒测试足够了）

黒盒也是白盒的一种

[泥泥]

呵呵，这个只是我们的一些经验而已嘛

是否百分比没有必要，还是90％没有必要，这个不同的人有不同的理解

至于黑盒也是白盒的一种，这个排除文字游戏的原因外，有什么特别的寓意吗？

[Daniel Teng]

Hi 

我会提一些实操性强的原则 :P

Daniel

2012/3/20 刘海阳 <liuha...@gmail.com>

摘要：

    我想利用敏捷的最佳实践提升所在Tools Team的开发质量，但是Tools开发的特点是：短周期，多项目，多语言，多环境，多需求来源，还有support类工作。所以做起来不太得心应手。

Team背景：

• 某互联网公司运维部门的Tools Team。
• 主要职责是给通过开发工具支持运维部门。现在阶段的主要工作：Zabbix监控/CMDB建模和实现/SSO部署/生产日志分析/Release&Build自动化等。
• 5人团队，我是新加入的，Java开发背景，其他同事是SA背景的开发。
• 开发语言主要是Python，但是为了完成需求，会用到各种语言实现的开源产品。大部分开源产品我们需要自己fix bug以及二次开发。

一些显而易见的问题：

1. 代码管理混乱
• 没有版本控制
• 历史原因：Java开发中Eclipse IDE搞定一切。现在面对不同的需求要用不同的语言在不同的OS和不同的工具上开发，例如Zabbix的bug fix就在linux上用VIM开发，CMDB前端的JS又是在window上开发的，每个人的开发习惯也不同，有人喜欢IDE，有人只用VIM。代码很难随时/方便的check in。

必须把所有东西纳入版本库，这是不可商量的原则。

组织必须把所有的知识资产（文档，代码，脚本，工具）版本化。这样组织才能把自己的资产回滚到上一个安全状态的能力。（注意：这可以不包括通过脚本生成的中间产物，比如二进制文件等）

开发语言与版本管理工具没有什么必然的关系。无论是什么语言，还是什么脚本，其实都是文本文件，都是可以纳入版本库的。把目标（组织知识资产管理）告诉给大家，当不同的人员去PK就可以，选出一个大家都能接受的方案就可以。如果推荐的话，用Git比较爽。

1. 上线代码没有review
• 没有版本控制的支持，想review也困难。

必须纳入版本管理。如果不Review，也可以采用结对。。。 

1. 没有质量管理
• Tools独立于PD，没有QA资源。代码质量只能自己保证。

职业人当然要为自己做的事情负责，不应该指望别人帮自己测试。 

1. 没有持续集成
• 其实这是一个伪问题，虽然这里没人认为CI是必须的，但是我实在是觉得没有CI真的是个问题。

必须要CI，要保证自己的东西是可用的，必须对自己做的东西的质量负责。 

每个问题或多或少和开发周期紧张有关系，其实每家公司情况都相同，这里就不提了。

所以，我希望和同学们讨论一下：

1. 在非IDE开发中怎么做版本控制最方便？
1. 强大的IDE+Plugin可以搞定一切，但是用VIM的同事怎么办？CLI自己搞定？

不要被IDE惯坏了，用命令行 

1. 用SVN/GIT简单，但是设计一个适用于多语言的code repository目录结构就麻烦了，有经验的同学共享一下。

辅助工具应该与它去辅助的产品放到一起，一起“成长”的。把工具与产品信息资产分离本来就是不理智的。要以产品为主导，把与产品相关的所有资产都放到一起，一起作版本，当然也包括相应的工具。 

1. 有没有必要推广TDD或者对单元测试有所要求吗？
1. 个人TDD观点：我个人是TDD的拥护者和实践者。但是，我认为TDD是无法强制推广的，因为TDD是程序员的个人思考方式和习惯。
2. 很多团队对代码有测试覆盖率要求，我认为这样是幼稚的。但是，我找不到其他更好的办法。所以，我纠结。

我想作有职业精神的员工作TDD有三个显而易见的好处：

• 在做一件事情之前，先设定一下目标状态应该是什么样子的，制定出一个好的实现策略（小步快走），然后去实现它。当然这个是跟个人习惯相关的。
• 确保自己做出来的东西，始终按照预想的状态、行为工作。这个是跟整个团队都相关的。
• 确保别人能够方便地了解工具的使用。这也是跟团队相关的。

第一个好处，其实是个人的选择，如果不用TDD，只要能够达到那个被其他人要求的目标也可以。因为它可以满足需求。

第二个好处，如果没有测试是比较难的，除非工具开发人员自己做人肉CI。

第三个好处，自动化测试其实就是文档，但是如果他能及时响应别人的询问，也是可以的。 

个人认为，第二个和第三个是合理的要求，最简单的方案是用自动化测试。

1. Shell脚本能单元测试吗？需要单元测试吗？
• 这方面不我不熟悉，刚才问了一下写Shell脚本的同事：Shell脚本能单元测试吗？同事乐了，Shell需要单元测试吗？

是否单元测试，这要看情况。但是总不能让工具开发人员靠拍胸脯保证没有问题，也不能总是靠测试人员不停人肉去保证质量。 

1. 同在Tools Team的同学分享点开发管理经验吧
• 在了解了自己Team的环境后，我觉得Scrum的一套在这里行不通。

也未必行不通，比如像Steven说的一天一个sprint?难道一天的响应速度还不够？

不过在我现在服务的客户那里，也有一个类似的工具团队，我帮他们引入了看板，应该是比Scrum更加适合一些。

但是

哪怕是看板，他们也有每三周一次的planning（当然每天还会根据紧急需求来调整)，也会有需求分析和梳理会议，也有站立会议，每三个星期也有Retrospective。不过他们的任务也是随时提交给其他团队的。 

• 我不可能为了某一个大点的项目组建一个Scrum Team。 大家都是跨项目工作的，干扰太大。

多任务这种方式是不Work的 

• 想过把所有来路的需求都放入backlog维护，但是我最终放弃了这个想法。我们要频繁交付，Scrum以周为单位的周期太漫长了。

用天为单位的Sprint？或者看板？。。。

但是无论是否Scrum哪怕是看板必须要做到的是：

• 在同一时刻同时在做的事情不能多于X个，过多的多任务并行是无效的。
• 做完一件事，再到backlog拿下一件事情。
• 所有的需求进统一的Backlog，有统一的优先级
• 开始的时候不可避免的会因为能力的问题，导致产出下降，但是长期下去，会促进团队的学习，而且总是学习优先级最高的那几个工具，从长远来看，这个投资有可能是值得的。
• 保证所有正在做和要做的几件事情事情的粒度，必须能够在很短的时间内完成（比如两天），而且完成是指交付。 

• 我想借鉴敏捷开发的最佳实践，但是我又不想直接照搬几个best practice了事。

最佳实践都是骗人的，跟万灵药差不多的东西。 

• 最终目的是：通过改进过程管理来达到提升Team整体开发能力的目的。

同意 

写邮件的同时也review了一遍自己的问题，似乎一切罪恶的根源都在于Tools Team这种零散式的开发。以前一直做Java项目/产品开发，整齐习惯了。

怎样在现在的环境下保持开发和代码的低熵有序，开始改进之前，真需要认真思考规划一下。

 

归根结底，其实不应该有工具团队这种团队，工具应该是由产品开发团队维护的。但这也是不得已的事情。

面向开发细节，大家有经验就分享下，high level的东西就别扯了，看着累。

谢谢

刘海阳

--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina

--
Best Regards
Daniel Teng, Certified Scrum Coach

http://www.danielteng.com/

[Daniel Teng]

2012/3/22 陈之过 <chenzh...@gmail.com>

> 在非IDE开发中怎么做版本控制最方便？（把目标文件夹放到SVN目录，做个自动脚本，监控文件夹，定时识别，一旦发现文件有变化，就自动submit一下，无论用啥工具编辑的，都可以如此做）

我觉得完全没有必要这样做!

同意，这其实是一种很傻的做法，尽管它比不做版本管理要好。

因为工具的开发其实是跟产品开发是相辅相成的，因此其实是应该与产品代码一起打版本的，可能因为某个产品的改动，而相应地对辅助工具做出了调整，它们是相辅相成的。而这时候反而要通过手动的提交代码，然后通过有意义的check in comment，来说出因果，这其实就是在记录产品演进的历史。而自动化check in首先会导致与生产代码脱节，其次是不可能通过工具产生“说人话”的check in comment。 历史信息就会丢掉。

[Liang Qiao]

再次佩服Daniel的耐心啦。

乔梁（Qiao Liang）

Blog: http://blog.csdn.net/tony1130

2012/3/22 Daniel Teng <tengz...@gmail.com>

[泥泥]

说的有道理，不过我所说的是过程改进的一些小工具，和产品代码完全不是一回事，举个例子，windows下的应用程序要做数字签名，我们做个小工具自动，使得autobuild出来的dll和exe文件签名，这是通用的，和产品本身没有关系。
之前说的自动检查文件改动的主要使用在服务器上一些自动脚本的变化和运行情况记录，这样日志文件不会因为故障而丢失。

另外，把工具和产品开发混为一谈这个我觉得很奇怪啊，要么T eng说漏了，简单的例子，hu dson算一个自动构建工具吧，哪个产品团队会在自己产品中自己接一套自动build框架？

[Daniel Teng]

Hi 

2012/3/23 泥泥 <nijp...@gmail.com>

说的有道理，不过我所说的是过程改进的一些小工具，和产品代码完全不是一回事，举个例子，windows下的应用程序要做数字签名，我们做个小工具自动，使得autobuild出来的dll和exe文件签名，这是通用的，和产品本身没有关系。
之前说的自动检查文件改动的主要使用在服务器上一些自动脚本的变化和运行情况记录，这样日志文件不会因为故障而丢失。

这正是一个好的例子，这些工具是要给你们build出来的dll, exe签名吧，所以当然要跟产品放在一起。给你一个场景，1000年后出了windows 3000，但是你们的客户还在用windows XP的版本，突然有一天，好好的程序不work了，给你报bug，但是翻箱倒柜已经找不到给xp系统上工具签名的小工具了。。。

为了支持产品运帷的工具及脚本当然必须给运维系统的代码，数据。。。放在一起，也是为了给整个系统留一个snapshot。 

我上面确实说漏了，把所有需要的工具（可能是二进制），包括hudson，自动化测试工具，甚至如果C＋＋的话，包括编译器等都要放到版本库。如果需要安装的，把安装文件也放到版本库（当然有时候由于其他原因，安装文件太大，不是很经济，但这就是一个取舍了）。

最近两个星期在公司里开始研究Chef，要实现的事情是，服务器以及开发环境的自动化安装和配置，而这些脚本其实也是可以放入版本库的。因此开发甚至运维环境都有可能用脚本重现了。

另外，把工具和产品开发混为一谈这个我觉得很奇怪啊，要么T eng说漏了，简单的例子，hu dson算一个自动构建工具吧，哪个产品团队会在自己产品中自己接一套自动build框架？

我指的是工具的选择（是否选择Hudson，还是Bamboo, TeamCity还是其他）、配置、定制、开发的权利其实是在产品团队的。把工具和产品开发放到一起道理很简单，只有使用工具的人，才知道工具应该做些什么，也没有关于工具需求的沟通成本。团队需要一个CI工具，因此它要去评估，可以去上网查，也可以去到其他部门取经，最终确定自己的工具。

按照近几年的CD的做法，其实运维和开发整个都串在一起了，是一个团队，因此运维工具也是产品工具的一部分。

当然从整个组织级别有其他考虑，有时候希望有一些工具的统一，比如Hudson，（一个常见的原因是老板可以坐在办公室里面，通过统一的界面去看报告），因此这就成了一个公司不同产品线选择自己工具的一个很重要的考虑因素。但是如果没有那些高高在上的指手画脚的团队的话，为什么产品团队不能选择自己的build框架？另外其实要用发展的眼光看这个事情，每个产品线都有自己的build框架之后，大家就会互相促进（当然组织方面要鼓励这种方式的共享或者良性竞争），这不是自上而下的，而是自下而上的，也会推动整个组织的工具和实践向前发展。

[Xu Yi]

简单点讲，就是所谓的Infrastructure as Code以及Configuration as Code。

- - - - - - - - - -
Xu Yi, Kaverjody
Senior Agile Consultant @ HP Enterprise Services
Blog : http://blog.sina.com.cn/kaverjody
Sina Weibo : http://weibo.com/kaverjody
Skype : kaverjody
- - - - - - - - - -

[刘海阳]

感谢大家的讨论和分享，特别是Daniel细致的回复。这些对我们的团队非常有帮助。

对于我们来说，我们当务之急要实现的是

1. 实现全部代码和配置的版本控制。
2. 通过PP或者review保证代码质量。

这些改进是“性价比”最高的。CI和UT/TDD当作一个中期目标，慢慢持续改进。

除此之外

• Daniel提到的引入Scrum看板。
• 之前自己思考如何改进的时候，忽略了“看板”。其实这也是一种 best practice 。看了看office的墙壁，还有空间 :D
• Steven提到的以天为单位的sprint。
• 这个之前也没想到过。因为我脑海里的sprint还是比较重的过程。这个对我很有启发。正好手头的项目有频繁发布的需求。 也许我抛弃对sprint的偏见，尝试一下“1人1天”的mini sprint。

通过讨论，我已经看清了解决问题的前进方向。当然，完美的改进路径是不存在的，作为实践者，目的永远比方法论重要。

我们的团队是一个非典型的开发团队，但是这样的Tools Team在各个公司(尤其是互联网运维部门)其实是普遍存在的。

所以作为open question，同学们有兴趣的话可以继续讨论。

再一次感谢大家。

[泥泥]

明白我们的分歧所在了。也理解Teng所说的理想状态了，这其实涉及不同的行业和领域了，比如快速消费类产品和工程设备类产品，企业经营方式和生产管理方式都不同的。

比如银行结算系统、和个人通用视频视频软件，生产模式差异可谓天差地别了，我们目前做的更接近后者。因为有市场需求（windows的UAC认证），签名需要的不仅仅是客户端小工具，还有第三方供应商，而第三方也需要微软给他的授权。

另外，我的确认同让Team来选择工具这件事情，不过我现在的确面临很大的压力，我们原有的很多项目管理工具是自己编写开发的，原因正如Teng所说，部分总监们依赖统一的报表来做管理，而不是走入现场。（当然随着组织规模的变大，走入现场貌似到了一定层级变得很困难），我视图说服Team根据自身出发评估第三方的工具，至少开源软件不需要投入现金成本，但很多人还是习惯先满足领导的需求。

这个事情任重而道远，我得去给各职能部门的头头们洗脑:)，不过貌似不会从一统江山的工具走到另外一个百花齐放的场景，最终，根据业务类型不同，会变成三到四中选择留下来。

很多人通过自己的努力上位，但遗憾的是，很多时候，他们把自己成功的路径想象成唯一可行的路径，主要的指导就是“同学们，跟着我的脚步走吧，别掉队。”

在 2012年3月23日 上午11:01，Daniel Teng <tengz...@gmail.com>写道：

[Yin Wenyan]

我的看法如下：
- 版本控制 | 必须的 | 低投入高产出
- 看板 | 挺好的，最好每个Tool一块看板，区分“待搞”、“正搞”、“搞定”，外加燃尽图 | 低投入高产出
- Daily build | 每个build可以独立交付（功能可以砍，虫子不能养）| 低投入->高产出
- PP或review | 不容易搞好，可尝试，期望降低些 | 高投入?产出
- 自动测试 | 有难度 | 高投入高产出
- 开发人员交叉测试 | 即一个Tool的开发去测试另一个Tool, 只测daily build，重点关注正常流程 | 低投入高产出
- CI | 不着急，开发小工具集成不是大问题 | 高投入?产出
- 确保"搞定"一致性 | 即team认为的“搞定”与end user认为的“搞定”要一致 | ?投入高产出

资源永远是短缺的，轻重缓急当自行斟酌。

[Elstage]

想问我下交叉测试基于daily build，每天都进行？

[漠河]

讨论个具体点的东西，像存储过程这样的脚本如何跟项目代码一起版本管理？

 

---

漠河

 

发件人： 陈之过

发送时间： 2012-03-22 11:22

收件人： agilechina

主题： Re: [agilechina] 讨论点实质性的东西吧-Tools Team的开发管理

[胡凯]

为何不行？ DBMigration + SQLUnit测试

2012/3/23 漠河 <rai...@gmail.com>

--

[张克强]

与项目代码一起存放即可啊。不知楼上有什么具体困难？

有些项目组在项目Source control的一级或二级目录为预留 名为 script的目录，来存放相应的脚本。

打基线时，一并处理即可。

[毛凌志]

弱弱的问一下，打基线的意思是打tag吗？有什么作用

[张克强]

打基线是更宽泛的说法，有不同的做法，打tag是实现打基线的其中一种方式。

作用是建立可供记录和回溯的基准。

[毛凌志]

这样啊，还有别的实现方式能举下例子吗，这方面不了解

[张克强]

常见的还有：建立基线目录，将所有基线内容放入（这个做法有点土：））。
对于有些功能强大Source Control工具，只需记录基线指定的时间。

配合不同Source Control工具，还有更多办法，请群中达人再举例。

[Elstage]

我们目前也是这么做的，项目目录下有个sql目录，存放存储过程。只是觉得存储过程的差异比对、重构什么的太费劲了。对于存储过程的设计大家有没有什么经验分享？

> 更多选项，请访问 http://groups.google.com/group/agilechina我们

--
你有什么不开心的事，说出来让我开心一下。

[皮宇]

其实存储过程不一定是最佳解决方案，不过的确有些软件系统为了追求执行速度，把所有业务逻辑写到存储过程中。我的建议是：
1.从大的方向上尽量避免使用存储过程，因为存储过程对数据库本身有严重的依赖，无论是性能依赖还是语言依赖。一旦换DBMS，风险就会陡增。可以考虑读写分离等方案，将查询放在某一台只读服务器上来做。或者使用一些OLAP模式，将原始数据转换为方便查询的报表数据。
2.使用更好的工具，例如对oracle支持最好的莫过于pl/sql
developer，该工具支持自动格式化sql，所以只要要求项目成员在提交SQL前，必须格式化sql，这样就和代码管理就近似一样了。

[胡凯]

>> 只是觉得存储过程的差异比对、重构什么的太费劲了。对于存储过程的设计大家有没有什么经验分享

这和代码相比有什么不同呢？ 存储过程是纯文本，可以对比差异。

存储过程会改变目标系统的状态，这样就可以加测试。有足够的测试就可以重构。

2012/4/3 皮宇 <ds3...@gmail.com>

--

[Xiao Peng]

可是存储过程的重构没有现成的手法指导，更别提工具或者IDE支持了。
=========================
肖鹏，ThoughtWorks资深咨询师
AD：TW招聘中。
Blog：http://xiaopeng.me

2012/4/4 胡凯 <iamk...@gmail.com>

[James.Tong(鼠标)]

测试覆盖率也没法测，虽然有if这种分支，但很多逻辑都是在查询语句里，覆盖率没啥价值。
Story涉及大的存储过程基本上无法分拆，容易造成瓶颈。
单元测试倒是有办法写，但你还要专门准备个库来搞，准备数据又是一堆烂事。最后集成测试，测并发，测压力，测出问题再优化，优化经常就是重写。悲催无极限。这都是麻烦事。人生苦短，能不找雷尽量不要给自己找雷。

best regards,
James

[漠河]

有在用QTP自动化测试的么？

[漠河]

同感，存储过程多了重构、优化、管理真是头疼

[Jeff Xiong]

QTP就是个垃圾。赶紧扔了吧。

2012/4/16 漠河 <rai...@gmail.com>:

--
Jeff Xiong
www.Gigix.me

[漠河]

这话怎么说，什么理由？

 

---

漠河

 

发件人： Jeff Xiong

发送时间： 2012-04-21 08:42

收件人： agilechina

主题： Re: Re: [agilechina] 讨论点实质性的东西吧-Tools Team的开发管理

[Jeff Xiong]

这要说理由我能写篇一万字的文章来发表。

这么说吧，你把QTP放到持续集成里跑过没有？

2012/4/21 漠河 <rai...@gmail.com>:

[漠河]

只是想用QTP做回归测试，目前是在一个主版本基础上不断修改，分支出各个项目。如何保证主版本的稳定性是个大麻烦。

 

---

漠河

 

发件人： Jeff Xiong

发送时间： 2012-04-21 10:40