[Trac 经验谈之（1）杂谈篇](http://blog.csdn.net/lanphaday/article/details/6609256) [Trac 经验谈之（2）杂谈篇补遗](http://blog.csdn.net/lanphaday/article/details/6658032) [Trac 经验谈之（3）工作流篇](http://blog.csdn.net/lanphaday/article/details/6620098) [Trac 经验谈之（4）报表篇](http://blog.csdn.net/lanphaday/article/details/6641391) [Trac 经验谈之（5）插件篇](http://blog.csdn.net/lanphaday/article/details/6654027) [Trac 经验谈之（6 完）插件篇补遗](http://blog.csdn.net/lanphaday/article/details/7100118) # Trac 经验谈之（6完）插件篇补遗 赖勇浩（[http://laiyonghao.com](http://laiyonghao.com)） 在插件篇中，主要介绍了我正在使用的插件，它们完成了许多项目中的需求。不过在寻找插件的过程中，看到不少很有用的插件，有些跟我使用的 0.13 版本不兼容，或者功能不如符合我们团队的文化。但我可以感受到这些插件的卓越，觉得值得在这里跟大家分享，因为也许它适合你。最后推荐一篇张阁老的博客《我用的trac插件》（[http://1.zdev.sinaapp.com/?p=78](http://1.zdev.sinaapp.com/?p=78)），可以作为我这个系列文章的非常好的补充。 ### Project progress statistics and quality metrics 主页：[http://trac-hacks.org/wiki/TracMetrixPlugin](http://trac-hacks.org/wiki/TracMetrixPlugin)。该插件能够可视化地显示项目的状态：通过统计生成一系列的表格和图片（见下图），让人直观了解到项目状态，比如质量矩阵和进度状态。它为项目管理者对项目情况的了解建立可靠的途径。不过我怕老板看到质量和进度后大惊小怪，所以我一直没有用它，哈哈哈。  ### Typed Ticket Workflow 主页：[http://trac-hacks.org/wiki/TypedTicketWorkflowPlugin](http://trac-hacks.org/wiki/TypedTicketWorkflowPlugin)。该插件能够为 Ticket 工作流增加一个类型：在创建的时候指定。比如当把工作搞定要转交给测试人员的状态“ready for QA”，通过 ready_for_qa.tickettype = task 设置能够让只有类型是 task 的 Ticket 能够转到这个状态。它能够进一步地约束工作流，这是一把双刃剑，用不用就全凭你的喜好了。 ### Add support for ticket dependencies to Trac 主页：[http://trac-hacks.org/wiki/MasterTicketsPlugin](http://trac-hacks.org/wiki/TypedTicketWorkflowPlugin)。该插件还是进一步地约束工作流。通过向 Ticket 增加 blocks 和 blocked by 两个字段，它可以统计可以 Ticket 的相互依赖关系，并能够生成漂亮的图片直观地了解项目的路径状态（见下图），对项目管理者及时了解项目进度中的瓶颈大有增益。我觉得美中不足的是不需要增加两个字段，只要设置 blocked by 就足够了，blocks 可以通过 blocked by 计算出来。  ### Test Manager plugin for Trac 主页：[http://trac-hacks.org/wiki/TestManagerForTracPlugin](http://trac-hacks.org/wiki/TestManagerForTracPlugin)。这个插件相当强大，不仅可以创建测试用例，并通过 Catalogs 概念来管理用例，甚至能够生成测试计划并跟踪它们的执行状态及输出。它还有一个特点就是不像其它类似的插件那样使用 Ticket 来存储测试相关的数据，它使用的是 wiki！这个插件的缺点是太强大、太复杂了，它的主页是我见过的所有 Trac 插件中最长的，因为包含了它巨长无比的帮助文档。最后奉上一张测试状态图。 

[Trac 经验谈之（1）杂谈篇](http://blog.csdn.net/lanphaday/article/details/6609256) [Trac 经验谈之（2）杂谈篇补遗](http://blog.csdn.net/lanphaday/article/details/6658032) [Trac 经验谈之（3）工作流篇](http://blog.csdn.net/lanphaday/article/details/6620098) [Trac 经验谈之（4）报表篇](http://blog.csdn.net/lanphaday/article/details/6641391) [Trac 经验谈之（5）插件篇](http://blog.csdn.net/lanphaday/article/details/6654027) [Trac 经验谈之（6 完）插件篇补遗](http://blog.csdn.net/lanphaday/article/details/7100118) # Trac 经验谈之（2）杂谈篇补遗 赖勇浩（http://laiyonghao.com）  ### 教训 ### 一定要有模板 嗯，我说的是每一个任务单（ticket）的描述。如果没有一个描述模板，你得到的很大可能是一堆完全不知所云的文本。使用 TicketExtPlugin 可以很方便地做到这一点（见插件篇）。下面是我使用的模板，其中需求和改进的模板由我“抄袭”自禅道。 ~~~ =======================改进========================= 建议参考的模板：作为一名<某种类型的用户>，我希望<某个功能的描述>更改为<另一个功能的描述>，这样可以<开发的价值>。 =======================需求========================== 建议参考的模板：作为一名<某种类型的用户>，我希望<达成某些目的>，这样可以<开发的价值>。 =======================缺陷========================== 缺陷表现： 重现步骤： 期望结果： ~~~ ### 一定要定制报表 多问一下用户，比如老板、经理、制作人和测试人员，了解他们想要弄明白什么信息，然后建立起相关的报表给他们方便地使用。这样才能更好的让他们跟进项目的状态，推进项目的进展。 ### 不要定义太多字段 因为 Trac 有 Custom Fields 概念，用户可以随意定义字段，事实证明过多的字段一点用处都没有。只有专业的测试人员会去设置类似功能组件、职能组件之类的选项，产品策划等人通常无视这些“小细节”，甚至优先级、里程都都是空的，或者默认的。 ### 没有必要设置开始、结束日期 现在我们有这样的选项的，但在我们团队，超过 9 成的任务单没有设置两个字段，我相信设置了这两个字段了的任务单，也会有 9 成都没能在这个期间内完成。对于开发人员来说，能够在预设的里程碑里完成任务单，就相当不错了。 ### 没有必要安装甘特图、日历图等插件 是的，在老板看来，盯着甘特图好像会有一种成竹在胸、一切尽在掌握的感觉。鼓起胆气跟老板说：放弃这自我良好的感觉吧，这玩意根本不准。另外霍夫斯塔特定律必须记在心头：软件开发的时间总是比想象的时间长，即使注意了霍夫斯塔特定律也是如此。出处：[http://en.wikipedia.org/wiki/Hofstadter%27s_law](http://en.wikipedia.org/wiki/Hofstadter%27s_law)。 ### 搜索 Trac 的搜索相当不给力，比如你搜索“中文”两个字时，它会告诉你没有匹配的结果，并给出一条警告： ~~~ 警告: 搜索查询太短。查询必须至少包含 3 字符。 ~~~ 操蛋啊，尼玛啊，咱这是中文啊……两个字符可以表示整个世界了有木有！但是目前我还没有搜索到有效的解决方案，如果你有办法解决这个问题，请留言告知。谢谢。（2011年8月4日更新：flyinflash 朋友在本文后留言，提到了解决方案，我把它整合到了接下来的小技巧这一节中）。 ### 小技巧 ### 选择 owner 只要把 Trac.ini 的设置改一下即可： ~~~ [ticket] restrict_owner = true ~~~ 不过这不是完美的解决方案，因为 Trac 默认是显示注册的账号，这种英文字母+数字组合的名字对中国人太不友好了，比较好的方案是装插件，见“插件篇”。 ### 继承 Trac.ini 经常要编辑 Trac.ini，容易出错。其实在 Trac.ini 加一个节 [inherit]，然后填好 file 设置，Trac.ini 就能从指定的 file 中继承设置。 ~~~ [inherit] file = /path/to/global/trac.ini ~~~ 如果有多个配置文件，那么需要用逗号（,）隔开。如果 Trac.ini 中又有相同的节项的话，父配置就会被 override，所以最佳实践是 Trac.ini 只有 [inherit] 这一节，然后所有的具体设置都放在不同的文件中给 Trac.ini 继承。 ### wiki 转 html 有时候需要把纯文本格式的 Wiki 转成 HTML 页面，比如发表到博客什么的。这时候可以使用这个方案：[http://trac.edgewall.org/wiki/CookBook/Scripts/StandaloneWiki2Html#no1](http://trac.edgewall.org/wiki/CookBook/Scripts/StandaloneWiki2Html#no1) ### 搜索（2011年8月4日更新） 把 trac.ini 中的 [search] 这一节进行设置，即可搜索较短的单词，如中文的“义乌”，解决上文说的搜索警告的问题（感谢 flyinflash 的贡献）。 ~~~ [search] min_query_length = 0 ~~~ ### Hacking 在这个系列发表之后，朋友 @SparkleZeng 在微博上评论说（见：[http://weibo.com/1764732124/xeT2KivsG](http://weibo.com/1764732124/xeT2KivsG)）：“trac最大的好处是你可以二次开发，最大的问题是你需要二次开发才用的比较舒服。”说得太对了！所以对于 Trac 用户来说，Hacking 是必经的阶段，可能只是翻开源码直接 hard code 几行，也可能是编写一个插件来增进体验或增加功能。 本来我计划独立地写一篇来讲 Hacking Trac 这个事的，但在写这个系列的过程中我认识到还是介绍“使用”经验为好，所以就把这一篇缩写成一节。与使用 Trac 不同，想要 Hack 它，至少要读 Trac Developer Documentation（[http://trac.edgewall.org/wiki/TracDev](http://trac.edgewall.org/wiki/TracDev)），而且有不少代码必须要了解。简单地直接在源码那里 hard code 几行就不需多方了，只要用好 find/grep 这两条命令就差不多了。 对于想要编写插件（Plugin）的家伙来说，Trac Component Architecture（[http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture](http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture)）是必读的，通过这篇文档才能了解到 Trac 的心脏—— trac.core 是如何实现一个易于扩展微型的组件内核的（显然，这对于我们设计自己的应用也有很大的借鉴和启发作用）。  清楚 Trac 组件架构的内核机制以后，相信大家对如何编写插件实现自己的功能已经胸有成竹了。这时候需要了解 Trac 的 Request Handling 流程（[http://trac.edgewall.org/wiki/TracDev/RequestHandling](http://trac.edgewall.org/wiki/TracDev/RequestHandling)），这里有两个漂亮的时序图交待了整个请求处理的流程。 跃跃欲试的你现在想动手了吧，不着急，先看一下 Writing Plugins for Trac（[http://trac.edgewall.org/wiki/TracDev/PluginDevelopment](http://trac.edgewall.org/wiki/TracDev/PluginDevelopment)），你可以在这里看到基础代码模板，如何发布、调试，还有你必须了解的 Extension Points（[http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints](http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints)）。 别以为你现在就可以开始了哦，如果你需要在数据库存储数据，那你还要了解清楚它的 Data Models（[http://trac.edgewall.org/wiki/TracDev/DataModels](http://trac.edgewall.org/wiki/TracDev/DataModels)）和Database Scheme（[http://trac.edgewall.org/wiki/TracDev/DatabaseSchema](http://trac.edgewall.org/wiki/TracDev/DatabaseSchema)）。 最后，为了让全世界人民都可以用上你编写的插件，你还需要了解一下它的本地化技术（[http://trac.edgewall.org/wiki/TracL10N](http://trac.edgewall.org/wiki/TracL10N)）。好吧，现在你可以动手了，最后送你一份 Trac API Docs一路伴随你（[http://trac.edgewall.org/wiki/TracDev/ApiDocs](http://trac.edgewall.org/wiki/TracDev/ApiDocs)）。 2011年8月4日更新：flyinflash 留言说：Trac开发文档可能有时会让人困惑，Plugin 和 Component 有时指同一样东西，应该加备注。

[Trac 经验谈之（1）杂谈篇](http://blog.csdn.net/lanphaday/article/details/6609256) [Trac 经验谈之（2）杂谈篇补遗](http://blog.csdn.net/lanphaday/article/details/6658032) [Trac 经验谈之（3）工作流篇](http://blog.csdn.net/lanphaday/article/details/6620098) [Trac 经验谈之（4）报表篇](http://blog.csdn.net/lanphaday/article/details/6641391) [Trac 经验谈之（5）插件篇](http://blog.csdn.net/lanphaday/article/details/6654027) [Trac 经验谈之（6 完）插件篇补遗](http://blog.csdn.net/lanphaday/article/details/7100118) # Trac 经验谈之（5）插件篇 赖勇浩（[http://laiyonghao.com](http://laiyonghao.com)） 如果说 ticket 是 Trac 的灵魂，那么把插件（plugins）称为 Trac 的血肉应不为过。因为这是使用的经验谈，所以 Trac 的插件机制原理什么的，我们就不谈了，就介绍一下我都有用哪些插件，这些插件的功能又是什么，解决了什么问题。 不过在这之前，还是需要先知道怎么查找、下载和安装插件。 Trac 的插件都在 [http://trac-hacks.org/](http://trac-hacks.org/) 网站上安家，所以去这里找插件就对了！里面的每个项目都有一个自己的页面，基本上下载、安装和配置都在上面写写清清楚楚的。一般可以选择下载 zip 格式的发布包，然后解压到某个目录下执行一下 python setup.py bdist_egg 把代码编译成 egg。再用管理员账号登陆 Trac，点击右上角的“管理（admin）”，在新页面选择左侧栏“一般（general）”下的“插件（Plugins）”链接，这“管理插件”页面右上角可以把之前编译好的 python egg 上传安装，然后编辑 trac.ini 文件进行配置即可。 接下来正式开始介绍插件，按体验和功能进行简单分类。 ### 体验 ### AutocompleteUsers 主页：[http://trac-hacks.org/wiki/AutocompleteUsersPlugin](http://trac-hacks.org/wiki/AutocompleteUsersPlugin)，我现在使用的是 0.4.1 版本，它的作用是在输入属主或抄送的时候，以 Ajax 的风格即时提示用户名，这样只记住用户名的前面一两个字母就行啦。效果图：  还有一个可选的类似插件叫 TracAutoCompletePlugin，见：[http://trac-hacks.org/wiki/TracAutoCompletePlugin](http://trac-hacks.org/wiki/TracAutoCompletePlugin) ### CcSelectorPlugin 主页：[http://trac-hacks.org/wiki/CcSelectorPlugin](http://trac-hacks.org/wiki/CcSelectorPlugin)。虽然通过编辑 trac.ini 把 [ticket] 节加上 restrict_owner = true，可以实现属主的列表选择，但是对于中国人来说，要记住别人的用户名实在是太困难了，因为有些人是用英文名、有些人用拼音名、有些人姓在前面，有些人姓在后面，最后的方式莫过于能够通过真实姓名来选择。这个插件就是解决了这个问题，效果图：  我对 CcSelectorPlugin 进行了硬编码式地 hack，实现了对 owner 的选择，算是 Trac 在用户选择方面最完美的解决方案了，等我整理代码后，择日开源给大家使用。 ### BreadCrumbsNavPlugin 主页：[http://trac-hacks.org/wiki/BreadCrumbsNavPlugin](http://trac-hacks.org/wiki/BreadCrumbsNavPlugin)，顾名思义，它的作用是解决用户想回到之前的页面却操作起来很麻烦的问题。启用这个插件后，在页面的右上角，就是登陆、设置等链接的那个地方，会多出一行链接，记录了你之前访问过的若干个页面，就像面包屑一样，找到“回家的路”。 ### DateFieldPlugin 主页：[http://trac-hacks.org/wiki/DateFieldPlugin](http://trac-hacks.org/wiki/DateFieldPlugin)，通过一些设置，这个插件能够实现日期的可视化输入和校验，效果图：  ### CustomFieldAdminPlugin 主页：[http://trac-hacks.org/wiki/CustomFieldAdminPlugin](http://trac-hacks.org/wiki/CustomFieldAdminPlugin)。自定义字段（custom fields）异常重要，很多体验提升的插件都是基于它的，如果你有兴趣去查看一下 Trac 的源代码，你会发现其实 Trac 在相当多的地方专门处理了 Custom Fields。这个插件提供了 Web 界面来管理自定义字段，比如增加、改变和删除等，而之前你需要直接编辑 trac.ini（这是一种危险的、容易出错的方式）。 ### 功能 ### TicketExtPlugin 主页：[http://trac-hacks.org/wiki/TicketExtPlugin](http://trac-hacks.org/wiki/TicketExtPlugin)，通过这个插件，可以实现：1）根据 ticket 的类型使用不同的描述模板；2）能够通过 TracAdmin 页面可视化地定位模板；3）根据 ticket 的类型可以使能或禁用自定义字段。我们通过这个插件，定制了自己的 ticket 描述模板，很好地引导了初次接触 Trac 的用户，解决了他们“不知道怎么用”的问题。 ### TracWysiwygPlugin 主页：[http://trac-hacks.org/wiki/TracWysiwygPlugin](http://trac-hacks.org/wiki/TracWysiwygPlugin)。Trac 不被团队中的非程序员成员拒绝使用，很大的一个原因莫过于他们觉得 Wiki 语法需要学习，太难。这个插件可以在一定程度上缓解问题，达到了部分的“所见即所得”效果，基本上所有用户都安装了这个插件。 ### GraphvizPlugin 主页：[http://trac-hacks.org/wiki/GraphvizPlugin](http://trac-hacks.org/wiki/GraphvizPlugin)。所有 Unix 粉丝都对 Graphviz 如雷贯耳吧？这个插件实现了对 wiki 中 graphviz 程序的解释，让大家能够写文本的 Wiki，看图形的效果。例子： ~~~ {{{ #!graphviz digraph G { rankdir = "LR" GraphvizPlugin [ URL=GraphvizPlugin ] Trac [ URL="http://trac.edgewall.org/" fontcolor=red ] GraphvizPlugin -> Trac } }}} ~~~ 效果图：  需要注意的是使用这个插件需要在机器上安装 graphviz 程序。 ### ChildTicketsPlugin 主页：[http://trac-hacks.org/wiki/ChildTicketsPlugin](http://trac-hacks.org/wiki/ChildTicketsPlugin)。这个插件功能强大，不过简单来说就是给 Trac 带入子任务单的概念。可以设置某个类型的任务单是否能够拥有子任务单，也可以限制它子任务单的类型，以及子任务单从父级继承的字段等。你即可以直接在某个任务单页面直接创建子任务单，也可以查看到当前所有子任务单的信息（字段是可以设置的），如下图：  还有一个SubticketsPlugin（见：[http://trac-hacks.org/wiki/SubticketsPlugin](http://trac-hacks.org/wiki/SubticketsPlugin)）提供类似的功能，但是我不喜欢这个插件，因为当增加子任务单时需要修改父任务单，这太操蛋了，而且定制性也弱很多。 ### TracTicketValidatorPlugin 主页：[http://trac-hacks.org/wiki/TracTicketValidatorPlugin](http://trac-hacks.org/wiki/TracTicketValidatorPlugin)。这是金山珠海的员工 Richard Liao 贡献的插件，提供了基于正则表达式的字段合法性校验，非常赞。还有一个很类似的插件叫 TicketValidatorPlugin（见：[http://trac-hacks.org/wiki/TicketValidatorPlugin](http://trac-hacks.org/wiki/TicketValidatorPlugin)），但我不喜欢，因为它是基于 ticket 的状态来验证的字段的合法性的，而且只提供弱爆了的 required 验证。 ### XmlRpcPlugin 主页：[http://trac-hacks.org/wiki/XmlRpcPlugin](http://trac-hacks.org/wiki/XmlRpcPlugin)，顾名思义，这个插件给 Trac 提供了 XML-RPC 机制，这样类似 TaskTrayTask 的客户端软件就可以通过 XML-RPC 定期查询 Trac，获得新的信息，并提供用户。除此之外，还有不少应用也依赖于它。使用时的注意事项就是需要给用户开通 XML-RPC 权限。 ### TracSqlPlugin 主页：[http://trac-hacks.org/wiki/TracSqlPlugin](http://trac-hacks.org/wiki/TracSqlPlugin)。这个插件应该很少人用，但是真的赞爆了！这个插件在你想 hack Trac 的时候非常有用。启用后，它在页面上增加了一个“SQL”的选项卡（右上角）。通过它可以：1）使用 SQL 语句查询数据库，2）查询格式化或未格式化的数据，3，导出数据为CSV，4）浏览数据库数据表结构。无论你使用提 SQLite、MySQL 还是 PostgreSQL 都可以使用这个插件。效果图：  to be continued...

[Trac 经验谈之（1）杂谈篇](http://blog.csdn.net/lanphaday/article/details/6609256) [Trac 经验谈之（2）杂谈篇补遗](http://blog.csdn.net/lanphaday/article/details/6658032) [Trac 经验谈之（3）工作流篇](http://blog.csdn.net/lanphaday/article/details/6620098) [Trac 经验谈之（4）报表篇](http://blog.csdn.net/lanphaday/article/details/6641391) [Trac 经验谈之（5）插件篇](http://blog.csdn.net/lanphaday/article/details/6654027) [Trac 经验谈之（6 完）插件篇补遗](http://blog.csdn.net/lanphaday/article/details/7100118) # Trac 经验谈之（4）报表篇 赖勇浩（[http://laiyonghao.com](http://laiyonghao.com)） 最近又花时间折腾了一下 Trac 的用户体验，hack 了一个插件来实现属主（owner）的选择，重点是能够显示用户填入的中文昵称，这样大家找起人来方便。不过今天我们不谈这个，花开两朵，各表一枝，继续谈计划好的报表篇。 Trac 的报表功能是很强大、很灵活的，除了本身提供的各种报表，还可以由用户自由定制。我不知道别人怎么定义 Trac 的报表这个术语，不过我是把 Trac 的路线图（RoadMap）和查看任务单（Report，这个翻译有点操蛋）都看作报表的，下面我们分别来谈一谈。 ### 路线图（RoadMap） 路线图中的重要概念就是里程碑（MileStone），里程碑可以指定一个逾期日，和一个完成日，分别表示预期完成时间和实际完成时间，通过这两个时间，可以看出是否存在延期或提前。每一个任务单（ticket）都有一个里程碑字段可供设定它所属的里程碑，乐观地说，如果能够把项目的需求、缺陷和改进都分析、细化到多个 ticket 中去，并设定好里程碑，那么整个项目的计划书就跃然纸上了。 在项目的推进中，不停地解决一些任务单，也不断地有新的任务单增加进来，也不停地有一些任务单被转移到其它里程碑中去，所以事实上里程碑里的任务单是不停地变化的。那如何才能快速、直观地了解里程碑的进度和健康程度呢？路线图报表就是用来解决这个问题的。  如上图，可以看到有 3 个里程碑，以及属于这些里程碑的任务单的状态。通过页面右上角的设置，还可以查看到已经完成的里程碑和做一些增进体验的设置，如隐藏没有截止日期的里程碑。这些里程碑的任务单状态分组是已经定制过的，所以可以看到已关闭、测试中和开发中三个状态的任务单数量，通过点击状态分组，可以进入此分组的任务单报表。定制状态分组通过编辑 trac.ini 来完成，首先确保 trac.ini 中有如下一节： ~~~ [milestone] stats_provider = DefaultTicketGroupStatsProvider ~~~ 然后加入一个名为 milestone-groups 的节，我所用的定义如下： ~~~ [milestone-groups] closed = closed closed.order = 1 closed.query_args = group=resolution closed.overall_completion = true closed.label = 已关闭 resolved = resolved resolved.order = 2 resolved.css_class = new resolved.label = 测试中 active = * active.order = 3 active.css_class = open active.label = 开发中 ~~~ 其中 closed、resolved 和 active 都可以随意定义，它们表示分组名（groupname）。每一个分组名的值是一个以逗号（,）分格的列表，每一个元素都是一个状态名；也可以使用一次星号（*），它匹配了所有尚未指定的状态。每一个分组都有 order、query_args、overall_completion、label 和 css_class 五个属性供你设定，它们的意义如下： 1. order：决定了进度条中的显示次序，越小的数值越排在前面； 1. label：显示的名字； 1. css_class：css样式类名，可以通过增加 table.progress td.<class>这种形式的 selector 来定义； 1. query_args：前文说过点击进度条色块或 label 会打开一个任务单查询报表，这个参数的结果会附到那个报表的 url 之后，用来定制报表的，比如重载分组方式，可以使用 closed.query_args = group=resolution； 1. overall_completion：一个布尔值参数，标识在计算完成度时此组是否作为已完成状态的组。 ### 查看任务单（Report） ### 内建报表 Trac 内建了 8 个基础报表，基本满足了一般项目的需要。不过商业项目毕竟不比开源项目，老板或项目经理往往想要更方便地方式来了解项目或里程碑的进展情况，这时候就需要定制报表。不过在此之前，我们先来了解一下内建的 8 个报表的功能先： 1. 活跃的任务单（active tickets）：非 closed 状态的任务单 1. 活跃的任务单按版本划分（active tickets by version）：分组方式为版本 1. 活跃的任务单按里程碑划分（active tickets by milestone）：分组方式为里程碑 1. 已接受的活跃任务单按属主划分（accepted, active tickets by owner）：accepted 状态的任务单，分组方式为属主 1. 全描述的已接受的活跃任务单按属主划分（accepted, active tickets by owner(full description)）：accepted 状态的任务单，分组方式为属主，显式完整的描述字段 1. 所有任务单（含已关闭的）按里程碑划分（all tickets by milestone (including closed)）：分组方式为里程碑的所有任务单（包括已关闭的） 1. 我的任务单（my tickets）：属主为我的任务单 1. 活跃的任务单，我的优先（active tickets, mine first）：所有任务单，但属主为我的排在前面。 为了方便查看我们的业务进展情况，我在此外还定制了 5 个报表，如下： 1. 最近变更的活跃任务单：获得最近的项目动向 1. 活跃用户单（按属主划分）：获得对组员工作压力得信息 1. 我发起的任务单：获得我发起的任务单现在的情况 1. 已解决的任务单：了解进入 resolved 状态但还没有通过 QA 人员检测的任务单 1. 已关闭任务单：获得已关闭任务单的情况，如了解它们的解决方案 新建的报表默认排在基础报表之后，为获得更好体验，你可以改变这些报表在数据库里的 ID 来重新排序，比如： ~~~ update report set id=5 where id=3; ~~~ 执行以后就可以把原来排得较后的报表排到前面（不过 ID 是 PRIMARY KEY，所以需要注意它的唯一性）。 ### 定制查询 Trac 的报表定制性很强，而且提供了图形界面的定制查询和基于 SQL Query 语句的新建报表，在这里我们先来谈一下较基础的定制查询，然后再深入到 SQL Query 语句及其注意事项。 点击报表（report）页面上部左右侧的定制查询连接就可以进入定制查询页面，一般地，已经在过滤器中加了属主和状态两个字段，并且下方也显示了当前的过滤结果，如下图：  过滤器字样下方的减号（-）按钮可以用来删除这个过滤器，每一个过滤字段都可以通过选择或填写来方便地设定过滤条件。在过滤器下面的“和”及“或”两个下拉框可以用来添加新的过滤字段，如类型、报告人等。 列字样的多选框用来选择需要在报表中显示的列，还有比较关键的是“结果分组”参数，可以按不同的 ticket 字段来分组，一般选择属主或状态。 选好参数以后，可以点击“更新结果”按钮查看效果，如果觉得满意，那么可以点击页面下方的“保存查询”把这个报表添加到报表页面了。 ### 新建报表 定制查询虽然方便，但失去了一些灵活性，Trac Reports 能够让用户使用标准 SQL SELECT 语句进行报表定制。点击报表页面下方的“新建报表”按钮，可以进入 SQL 或 TracQuery 的编辑页面，定义好标题和它的描述，然后把 SQL 语句填入查询框，再保存报表即可。如“按优先级和时间排序的所有活跃任务单”报表的查询如下： ~~~ SELECT id AS ticket, status, severity, priority, owner, time AS created, summary FROM ticket WHERE status IN ('new', 'assigned', 'reopened') ORDER BY priority, time ~~~ 使用这种复杂的方式，是为了获得更丰富的能力，比如在查询中使用变量。这个规则解决，以$开头的单词将被看作变量，如： ~~~ SELECT id AS ticket,summary FROM ticket WHERE priority=$PRIORITY ~~~ 这个 $PRIORITY 就是变量，它的值由报表页面的 URL 传进来： ~~~ http://trac.edgewall.org/reports/14?PRIORITY=high ~~~ 除了定量，还有一些默认的特殊变量（或称为常量），现在只有一个，$USER，使用这些特殊变量时需要改变 URL，Trac 自动地传递它的值，如查询属主为自己的任务单： ~~~ SELECT id AS ticket,summary FROM ticket WHERE owner=$USER ~~~ 除此之外，Trac 还有自己的黑魔法——对一些字段自动格式化，主要有： - ticket：修饰为带 ticket url 超链接 - created, modified, date, time：把字段格式化为日期和（或）时间 - description：使用 wiki 引擎处理 还有 ID 和 realm 字段，不过这两个字段得不多，就不介绍了。除了字段自动格式化，还可以定制列格式、改变报表行的布局等。 ### wiki中的报表 有时候我们需要在 wiki 页面中引用一些报表，这时候可以使用 TracQuery（它也可以替代 SQL 用在新建报表中）。它是 Trac 用来显示符合特定需要的任务单的。比如你可以在 wiki 中写入如下语句： ~~~ [query:status=new|assigned|reopened&version=1.0 对应1.0版的活跃任务单] ~~~ 那么 wiki 引擎将把它渲染为一个指向 http://www.example.com/trac/query?status=new&status=assigned&status=reopened&version=1.0&order=priority 的超链接（锚文本是对应1.0版的活跃任务单），可以看到这个 URL 的参数正是 Query 语句的值。 Trac 强大的 wiki 引擎还可以使用 [[TicketQuery]] 宏把整个报表嵌入到 wiki 中，如： ~~~ [[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter,rows=description)]] ~~~ 以上宏表示显示按 ID 倒序排前 3 的已关闭的任务单，每条任务单显示处理结果（resolution）、概述（summary）、属主（owner）和报告人（report），然后再另起一行显示任务单的描述（description）。 to be continued...

[Trac 经验谈之（1）杂谈篇](http://blog.csdn.net/lanphaday/article/details/6609256) [Trac 经验谈之（2）杂谈篇补遗](http://blog.csdn.net/lanphaday/article/details/6658032) [Trac 经验谈之（3）工作流篇](http://blog.csdn.net/lanphaday/article/details/6620098) [Trac 经验谈之（4）报表篇](http://blog.csdn.net/lanphaday/article/details/6641391) [Trac 经验谈之（5）插件篇](http://blog.csdn.net/lanphaday/article/details/6654027) [Trac 经验谈之（6 完）插件篇补遗](http://blog.csdn.net/lanphaday/article/details/7100118) # trac 经验谈之（3）工作流篇 赖勇浩（[http://laiyonghao.com](http://laiyonghao.com)）  Trac 的工作流 ticket-workflow 其实是一个状态图。一个 ticket 从出生到消亡，经历许多状态，相关人员的工作（Action）推动着这些状态变化。在早期，Trac 的 ticket-workflow 是很简陋的和固定的（见上图），显然，这并不能普适广大用户的需求，所以自 0.11 版本开始，Trac 抛弃了之前固定的 ticket-workflow，开始使用可以由用户自定义的 ConfigurableTicketWorkflow，至此，针对 ticket 的工作流可以由插件控制。下面我们先回顾一下 v0.11 新的默认工作流，并从中了解一些基本概念，如状态（state），动作（action）等：  如上图，每一个节点称为状态（state），而连接结点的有向边称为动作（action），由状态和动作可以构建出状态转换表。上图共有 new、assigned、accepted、reopened 和 closed 等共 5 种状态，每一条 Ticket 必定处于这些状态之一。当一个动作（action），如 reassign、accept、resolve 或 reopen 作用在其上时，它的状态就改变为下一个状态。通常而言，不同的状态意味着这个 ticket 正在由不同的团队负责完成其中的一部分工作，并将在这个团队完全其所负责的这部分工作后，转换到下一状态。关于此点一一说明如下： - new：新建一个 ticket，所有新建的 ticket 都处于这个状态，一般来说，应该任何人都可以新建 ticket; - assigned：当 ticket 的 owner 发生改变，而 owner 又未 accept 时处于此状态；意味着这条 ticket 还没有人负责； - accepted：ticket 已经被接受；意味着开发团队正在开发功能或修正缺陷； - closed：ticket 被关闭；意味着 QA 团队正在测试或已经通过测试 - reopened：ticket 被重开，意味着 QA 团队发现功能未开发完成或缺陷未修复，重新指定 owner 负责跟进。 我们团队刚开始时使用默认的 basic-workflow，后来发现有几点不足： 1. reopened 状态让美术、策划很难理解，容易产生困惑，而且配置的时候多一个状态，麻烦不少； 1. 缺乏一个专门用以 QA 团队的状态，看到 closed 的 ticket 无法确定这个功能是否已经通过验证或缺陷修复是否已经通过回归测试。 针对上述问题，我们通过编辑 trac.ini 文件的 ticket-workflow 一节，定制了自己的工作流，我们工作流的状态转换图如下：  通过上图，可以看到工作流的主线 new->accepted->resolved->closed，比上面的版本都要明晰。我们去掉了 reopened 状态，代之以 assigned 状态，因为这两个状态本来就很相似，当 reopen 一个 closed ticket 时，需要指定一个 owner，并进入到 assigned 状态，其中关键配置是： ~~~ reopen.operations = del_resolution,set_owner ~~~ 此外，我们增加了一个 resolved 状态，它表示开发团队认为该功能已经开发完成或缺陷已经修复，并交由 QA 团队跟进测试，其中的关键配置是 ~~~ resolve.set_owner = tester1, tester2 ~~~ 它把能够接受 resovled 状态的 ticket 的 owner 限定为测试人员，其中 tester1 和 tester2 是测试人员的用户名。这个 (action).set_owner 设置项是一个不传之秘，一般人都不知道咧。 只有 resovled 的 ticket 才能转换到 closed，这个动作叫 test，明确地把 QA 的重要性体现了出来，也体现了从提出问题->解决问题->验证方案->结案记录的完备流程。 最后，给出我们的工作流的完整配置： ~~~ [ticket-workflow] leave = * -> * leave.default = 1 leave.operations = leave_status accept = new,assigned -> accepted accept.operations = set_owner_to_self accept.permissions = TICKET_MODIFY reassign = new,assigned,accepted,resolved -> assigned reassign.operations = set_owner reassign.permissions = TICKET_MODIFY reopen = closed -> assigned reopen.operations = del_resolution,set_owner reopen.permissions = TICKET_CREATE resolve = assigned,accepted,resolved -> resolved resolve.operations = set_owner resolve.permissions = TICKET_MODIFY resolve.set_owner = tester1, tester2 test = resolved -> closed test.operations = set_resolution test.permissions = TICKET_MODIFY ~~~ to be continued...

[Trac 经验谈之（1）杂谈篇](http://blog.csdn.net/lanphaday/article/details/6609256) [Trac 经验谈之（2）杂谈篇补遗](http://blog.csdn.net/lanphaday/article/details/6658032) [Trac 经验谈之（3）工作流篇](http://blog.csdn.net/lanphaday/article/details/6620098) [Trac 经验谈之（4）报表篇](http://blog.csdn.net/lanphaday/article/details/6641391) [Trac 经验谈之（5）插件篇](http://blog.csdn.net/lanphaday/article/details/6654027) [Trac 经验谈之（6 完）插件篇补遗](http://blog.csdn.net/lanphaday/article/details/7100118) ================= # Trac 经验谈之（1）杂谈篇 赖勇浩（[http://laiyonghao.com](http://laiyonghao.com)） ### 杂谈 ### 简介  Trac是一个基于Web的，轻量级的项目管理工具，它使用python语言编写，官网：[http://trac.edgewall.org/](http://trac.edgewall.org/)。它集成了增强的Wiki功能和版本控制功能，并可通过插件扩展其功能。 Trac 的用户大大的有！像 NASA 这样的机构都有团队（或项目）使用 Trac。像开源的项目如 JQuery、Django、C++ Boost 自然不在话下。但信不信由你，其实连 Virtual Box 这样的项目，都是用 Trac 的噢！国内也有不少企业使用 Trac，比如豆瓣、金山，特别是金山，总结了很多 Trac 方面的经验，他们的过程改进经理 ZoomQuiet 还编写一了份幻灯《金山在如何使用Trac》（见：[http://zoomquiet.org/res/s5/100123-KTRACintro/](http://zoomquiet.org/res/s5/100123-KTRACintro/)），是一份极具价值的参考资料。 ### 安装 Trac 的安装是很容易的，如果是在 linux 上安装，只要 Follow 官方的 guides 一路走下去就行；不过 windows 下的话，就有点操蛋，不过你可以参考一下官方的《Trac On Windows》（适用于 0.9/0.10/0.11 版本，见：[http://trac.edgewall.org/wiki/TracOnWindows](http://trac.edgewall.org/wiki/TracOnWindows)），或者我在 2010 年 3 月写的《在 windows 下安装和简单配置 trac 0.12》（见：[http://blog.csdn.net/lanphaday/article/details/5374066](http://blog.csdn.net/lanphaday/article/details/5374066)）。 我用的版本是 0.13dev-r10734，直接从 svn co 源代码安装的，过程跟我前面提到的文章差距不大，所以基本上也适用于 0.13dev。 ### 推广 在推广方面，我的看法是非常艰难的。我曾经在三个团队推广 Trac，只有一个成功了。第一个是在一个新建的小团队里，我作为技术顾问，推广 Trac，团队里有个很有激情和钻研精神的同学，把 Trac 调整得很好，但后来还是失败了。因为刚开始，产品、策划人员不习惯在 Trac 里通过 wiki 语法写文档，所以里面的 tickets 数量很少；等产品进入测试阶段的时候，那个同学已经离职了，产品人员也没有养成使用 Trac 进行缺陷跟踪的习惯和意识，所以就废了。 第二个是在某华南的网游大厂旗下的工作室里，我在那边的角色是一名普通的开发人员。我说服了技术管理者共同推广 Trac，并挤时间写了教程，做了培训。但是产品人员表面上同意使用 Trac，实际则从不向里面提交 ticket，于是退化成程序组内部的 wiki。在这个项目呆了 16 个月后，我因为觉得这个项目组缺乏规划和管理，再多一年时间游戏也上不上市，所以离开了。后来听留在项目组的同事讲之前我安装、配置的 Trac 早已经人走茶凉，不知觅处了。 第三个就是在我现在这个团队。我们的整个团队也是从零开始组建的，边组建边进行开发，到现在有差不多 40 个人进一个横版过关动作类 webgame 项目的开发，一年时间，项目已经上线了。到目前为止，我们已经建立起依托于 Trac 的工作流程，做到了较快速、较灵活的响应。在这个团队成功推广 Trac，我觉得利益于两点： - 一是来自行政权力的保障，公司老总虽然之前从未用过 Trac，但他试用、评估之后，看出了 Trac 的潜力，给了我大力的支持；而我的技术负责人角色，也可以制定规则，并有力地保障执行； - 二是我们及早地引入了测试人员，这一点利益于我在前文提到的网游大厂的工作经历，通过测试人员，我们把很多问题细节摆上 Trac，再通过测试人员的推动，先由程序、策划部门养成了使用 Trac 的习惯，再慢慢地影响到整个团队。 宗上述经验，我总结出如果没有行政权力，想靠自觉来在一个多角色的部门推广 Trac 无异于痴人说梦，而且 Trac 需要有比较熟悉的人可以随时提供手把手的一对一教学服务才能够让策划、美术等人用起来。最后给出一些推广可用的资料： 1. 《金山在如何使用Trac》[http://zoomquiet.org/res/s5/100123-KTRACintro/](http://zoomquiet.org/res/s5/100123-KTRACintro/) 1. 《trac 推广 ppt 分享》[http://blog.csdn.net/lanphaday/article/details/5436403](http://blog.csdn.net/lanphaday/article/details/5436403) 另外，送给有志于推广 Trac 的朋友几句话（From ZoomQuiet）： - 想用，就用起来了！ - 要和具体流程结合，就结合了！ - 不想用，怎么也不会用的（wiki 太难用；界面太难看；好复杂，学不会；）…… ### 替代品 使用 Trac 这么久了，很多优点、缺点都看到了，优点我觉得没什么好说的，仁者见仁；但 Trac 的缺点不少，我在这里数一下： 1. 不支持多项目， 1. 需求和缺陷没有分离， 1. 用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了， 1. 中文化不完整，美术人员接触起来困难重重， 1. 不显示中文名，本地化做得很差， 1. 核心功能很少，不安装插件基本上没法用。 所以虽然现在这个团队已经习惯了使用 Trac，但日后如果有新的项目，我还是想转到一个更好的项目管理系统上来。目前我比较看好的就是禅道（[http://www.zentao.net/](http://www.zentao.net/)），从它的官网拷来介绍如下： 禅道项目管理软件(ZenTaoPMS)是一款国产的，基于LGPL协议，开源免费的项目管理软件，它集产品管理、项目管理、测试管理于一体，同时还包含了事务管理、组织管理等诸多功能，是中小型企业项目管理的首选。禅道项目管理软件使用PHP + MySQL开发，基于自主的PHP开发框架──ZenTaoPHP而成。第三方开发者或者企业可以非常方便的开发插件或者进行定制。 作为中国人开发的开源项目，基本上完全解决了上面的几个问题。除此之外，禅道自身也有自己的 host 无忧在线项目管理（[http://www.5upm.com/](http://www.5upm.com/)），可以在上面免费托管自己的项目。最近推出的新版本甚至支持架设到 Sina App Engine 上去，这样可以几乎无成本地获得一个外网可访问的、稳定的禅道系统，吸引力非常大。 不知不觉写得太多了，接下来谈一下 Trac 工作流及其定制，to be continued...

赖勇浩（http://laiyonghao.com） 因为 CSDN 博客无法内嵌 SlideShare 的播放器，只好转成图片放在这里了。 想观看放映形式和喜欢下载的，请自行前往：[http://www.slideshare.net/laiyonghao/trac-3599973](http://www.slideshare.net/laiyonghao/trac-3599973)                        

赖勇浩（http://laiyonghao.com） Trac是一个基于Web的，轻量级的项目管理工具，它使用python语言编写，官网：http://trac.edgewall.org/。它集成了增强的Wiki功能和版本控制功能，并可通过插件扩展其功能。由于插件众多、功能全面，甚至可以与很多商业的CMS系统媲美，因此应用也日益广泛。它的ticket管理及工作流插件(http://trac-hacks.org/) 使得它也可以很方便地进行简单的业务协作及流程控制。  0、确保已经安装好 python 和 setuptools。python 的版本至少要 2.4（我使用 2.6.2 版本），setuptools 至少要 0.6。 1、使用 setuptools 安装 docutils、pygments 和 pytz，就是进入命令行执行 easy_install xxx 即可，嗯，确定要先连通互联网。 2、从 svn 安装 Genshi、Babel 和 Trac，通过 easy_install 安装的版本太低，会挂掉。我统一把它们安装到 D:/edgewall 。 svn co http://svn.edgewall.org/repos/babel/trunk babel svn co http://svn.edgewall.org/repos/genshi/trunk genshi svn co http://svn.edgewall.org/repos/trac/trunk trac svn co http://www.unicode.org/repos/cldr/tags/release-1-7-2/common/ cldr svn co 之后，进入 genshi 目录，执行 python setup.py install 安装好。 然后进入 babel 目录，执行一下 python ./scripts/import_cldr.py ../cldr，把 cldr 的导入，这是正确安装多语言版本必经的一步。一定要注意。cldr 导入完成后再执行 python setup.py install，这是必须的。 接下来进入 trac 目录，需要注意一下是我们要使用中文翻译，所以要进入 trac 的目录执行一下 python setup.py compile_catalog -f，把语言包编译成本地的版本。再执行 python setup.py install 就行了。 先简单验证一下安装有没有成功，在任意目录执行一下 tracd，如果出现 tracd 的 usage 就对了： Usage: tracd-script.py [options] [projenv] ... 3、创建项目环境。在任意目录执行：trac-admin D:/trac_prj initenv 就可以在 D:/trac_prj 建立新的项目环境。 在建议环境的过程中，它会问你项目名字，这个随喜了，我就输入了一下 test，也会问你数据库设定，我使用了默认的 sqlite，所以随手甩了个回车就搞定了，然后就看到命令行吐出一堆字符，不理，最后一行是 Congratulations! 就表示项目环境建立成功了。不过我也没有见过不成功是怎么样的，囧。 4、然后测试一下，在命令行执行：tracd -p 8080 D:/trac_prj，然后打开浏览器，输入 http://127.0.0.1:8000/trac_prj 就可以看到 Trac 页面了。好，接下来就是用户验证。 5、tracd 有个 auth 参数，可以指定验证规则，不过 tracd 是使用 Apache 的 .htpasswd 文件来保存的，在 linux 下还可以方便地用 htpasswd /path/to/env/.htpasswd username 来增加，在 windows 下就没有那么容易了。幸好 trac 提供了一个 python 脚本（见 http://trac.edgewall.org/demo-0.12/wiki/TracStandalone#GeneratingPasswordsWithoutApache）可以很方便地生成账户和密码文件。把这个脚本保存下来，命令行执行一下 python trac-digest.py -u username -p password >> c:/digest.txt，就可以把新用户加入 c:/digest.txt 中了。然后在启动 tracd 时使用如下命令： tracd --port 8000 --auth=proj_name,c:/digest.txt,trac c:/path/to/proj_name 这时即可登录 trac 系统。

> 原文出处：[Trac 经验谈](http://blog.csdn.net/column/details/trac.html) 作者：[gzlaiyonghao](http://blog.csdn.net/gzlaiyonghao) **本系列文章经作者授权在看云整理发布，未经作者允许，请勿转载！** # Trac 经验谈 > 介绍基于 Python 开发的项目管理系统 Trac 及其使用的一些经验之谈。