4.7　完備記錄，充分展現(xiàn)

說到與軟件交付相關的各種工具，其大體上分為兩類：一類是能夠自動化地執(zhí)行、自動化地往前推進流程的工具（我們前面講過）；另一類是輔助人工作的工具。怎么輔助呢？主要是把所有有用的信息都記錄下來保存好，讓想獲得它們的人能夠隨時方便地查看。就好像我們?nèi)粘Ｉ铍x不開眼睛，組織團隊共同協(xié)作也離不開各種記錄和呈現(xiàn)：我們想知道當前進展，我們想知道下一步要做什么，我們想知道問題是在哪里發(fā)生的、是如何發(fā)生的。

不僅是“我們”想知道，“他們”也想知道。有些組織對預算執(zhí)行情況有非常嚴格的審計制度，并且對過程成果物的數(shù)量和完整度也有很高的要求。如果“我們”工作的過程、狀態(tài)、結(jié)果可以被自動化地記錄下來，并被自動化地統(tǒng)計、整合、歸檔以供審計，那么就會節(jié)省很多額外的人工投入，而且自動記錄比人工記錄更客觀、更可信。

4.7.1　任務及其執(zhí)行情況

對于對工作項的記錄和跟蹤，比如缺陷、需求（如用戶故事）、開發(fā)任務等，都是工作項。記錄工作項的目標和內(nèi)容、相關詳細情況，然后跟蹤它們，看它們的狀態(tài)流轉(zhuǎn)過程，直到完成。這是工作項管理工具（或稱為變更請求管理工具）提供的基本能力。

當我們建立Scrum中的Sprint Backlog，并且以精益看板墻的形式展現(xiàn)它們時，計劃和進度就變得透明、直觀。

對于流程狀態(tài)，在工作項管理中常會設置一些狀態(tài)流轉(zhuǎn)的規(guī)則，比如對開發(fā)人員標記為“已完成”狀態(tài)的缺陷，只能執(zhí)行“通過驗證”操作到“關閉”狀態(tài)，或者執(zhí)行“重新打開”操作回到“待解決”狀態(tài)。這其實已經(jīng)有一些流程自動化的成分了。而在4.4節(jié)中提到的工作流和流水線，流程自動化的成分就更多了。然而，不論有多少流程自動化的成分，它們都還同時具有最基本的能力——記錄和展現(xiàn)流程的狀態(tài)：執(zhí)行成功了還是失敗了，執(zhí)行到哪一步了，是否需要人工干預，等等。

對于執(zhí)行細節(jié)的記錄，不論是在開發(fā)人員的本地環(huán)境中還是在流水線上執(zhí)行一次構(gòu)建，當構(gòu)建出錯時，都要分析和定位問題出在哪里，此時構(gòu)建的日志就很重要。類似地，部署的日志，以及自動化測試的日志和報告也很重要，它們都是用來幫助排查問題的。

軟件運行的日志，特別是生產(chǎn)環(huán)境中軟件運行的日志，在很大程度上也是為了在出現(xiàn)問題時方便定位和排查。在生產(chǎn)環(huán)境中還要配備各種監(jiān)控，這不僅僅是為了告警，也是為了對問題進行定位和排查。對微服務間調(diào)用鏈路的記錄，也有助于定位和排查問題。

總之，我們需要工具輔助記錄工作項的目標和內(nèi)容、進展情況、執(zhí)行細節(jié)。

4.7.2　版本和配置信息

上面介紹的主要是關于軟件的價值流動（或者說是變更請求流轉(zhuǎn)）方面的信息，下面介紹關于軟件內(nèi)容本身的信息。

“源代碼”需要被納入版本控制中。這里的“源代碼”加了引號，表示所有長得像源代碼的，也就是由人寫的、可以用文本文件記錄并且可能會有版本變化的內(nèi)容，都應該被納入版本控制中。比如與構(gòu)建、部署、環(huán)境相關的各類腳本和配置文件，數(shù)據(jù)庫表結(jié)構(gòu)或其變更腳本，測試用例和腳本等。典型的，如把它們放進Git或SVN這樣的版本控制工具中管理。而當我們使用版本控制工具中的提交、分支、版本標簽等功能時，要遵循相應的規(guī)范，以便日后進行各種查找。

納入版本控制不一定是放到Git或SVN這樣的版本控制工具中。簡單記錄下來是誰、什么時候、做了什么改動、改成了什么樣子，也就具備了最基礎的版本控制能力。典型的，如一個測試用例的修改變化歷史、一條流水線的配置的修改變化歷史、一個工作項的修改變化歷史，可能分別是由測試用例管理工具、流水線、工作項管理工具本身提供的版本控制能力實現(xiàn)的。

相比之下，版本控制工具所能提供的高級能力是，可以把相關的眾多文件內(nèi)容納入一個代碼庫中，放在一起管理，可以使用版本標簽之類的方式標識整體的版本，可以使用分支來跟蹤整體在不同方向上的分頭演進。

如果要管理的資產(chǎn)不是由人寫的，而是由“源代碼”自動“構(gòu)建”生成的，那么其對應的就是制品管理[2]。比如安裝包、編譯時用的庫、Docker Image等，它們也有版本，也要遵循相應的規(guī)范。

制品管理工具就是專門用來管理制品的，它為制品提供了一個安全的存放地，并且由于其具備良好的存放結(jié)構(gòu)，使得我們易于找到一個制品或它的特定版本，以便下載或者查看相關信息。

就像納入版本控制不一定要將“源代碼”存放到版本控制工具中一樣，納入制品管理也不一定要將制品放到制品管理工具中。比如代碼自動掃描的報告、自動化測試的報告，通常就直接存放在相應工具的相應服務中，只要能安全地存放、易于找到，那么就算是對制品有了基本的管理。

注意，以上版本控制和制品管理的對象，不僅包括管理公司內(nèi)部的資產(chǎn)，也包括外來的資產(chǎn)。常見的做法是把外來的資產(chǎn)納入公司內(nèi)部的代碼庫、制品庫中，并且在納入時要做一些質(zhì)量與安全方面的控制。

版本控制和制品管理的對象是軟件的內(nèi)容，而對于它們是如何組成運行中的軟件系統(tǒng)的，也需要記錄和管理。例如，某個測試環(huán)境實例包括哪些微服務、每個微服務用的是哪個版本、部署在哪些服務器上、歷史上是什么樣子的，等等，這些都是需要記錄和管理的。

4.7.3　關聯(lián)關系

上面討論的所有要記錄的內(nèi)容，它們之間有各種各樣的關聯(lián)關系，這些關聯(lián)關系也應該被記錄下來，最好是被自動記錄下來。

比如，對源代碼的修改應該和需求、缺陷等工作項相關聯(lián)。進而，當在流水線上向測試環(huán)境中做部署時，應該能自動查詢到所要部署的特定版本中包含了自上次發(fā)布以來哪些特性分支的合入，以及分別對應于哪些工作項。于是，測試人員就能知道所要測試的內(nèi)容。類似地，在向生產(chǎn)環(huán)境中做部署前，也應該能看到相應的信息，檢查所要部署的內(nèi)容是否正確。

比如，測試用例或者自動化測試腳本（準確地講，是對它們的改動）應該與用戶故事之類的工作項相關聯(lián)。于是，測試人員可以根據(jù)要測試的用戶故事自動選擇執(zhí)行哪些測試用例。而在測試過程中發(fā)現(xiàn)的缺陷，應該與發(fā)現(xiàn)它的人工測試用例或者自動化測試腳本，以及當時的執(zhí)行上下文相關聯(lián)。這些關聯(lián)關系都應該是自動建立的，而不是人工一項一項填寫的。有了這些關聯(lián)信息，就可以方便地查看該缺陷的所有相關信息，比如測試用例、相關需求描述、測試版本、測試日志等，找出問題所在。

4.7.4　單一可信源

不論記錄和展現(xiàn)的是任務及其執(zhí)行情況，還是版本和配置信息，抑或是各種關聯(lián)關系，都需要遵循一個基本原則，即：單一可信源（Single Source Of Truth，SSOT）。在獲取數(shù)據(jù)、信息、文件、制品時，不論是誰，想在哪個流程階段、哪個環(huán)境中，通過人工還是自動方式，都應當從同一個地方獲取，以保證總是獲取到相同的內(nèi)容，這個地方就是“單一可信源”。

當然，如果從不同的地方獲取，但這些地方之間有很好的同步機制，共同信任一個單一可信源并保證總是與它的內(nèi)容相同，那么也是滿足單一可信源這個基本原則的。

4.7.5　相關支持

從權(quán)限的角度來看，上面討論的所有要記錄的內(nèi)容，應該盡量讓相關人員都能看到。為降低設置和管理權(quán)限本身的成本，可以考慮一般內(nèi)容組織內(nèi)部全員可見，只對重要的或敏感的信息做進一步的權(quán)限控制。

此外，在工具和服務層面，要注意做好數(shù)據(jù)備份。在版本控制服務中存放著源代碼等重要內(nèi)容，對它進行數(shù)據(jù)備份格外重要。對制品管理服務中存儲的制品也要做好備份。工作項管理等工具中也保存了重要數(shù)據(jù)，需要做好備份。