[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...
