本文轉自微信號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！本文轉自微信號EAWorld。
編者按：很多行業身處強力監管領域，因而格外強調合規性。反映在IT上就是開發、部署和運維等規範（比如開發團隊不能碰生產日誌）的不可或缺。本文中提到的一些方法（如自動化測試、自動化合規性及安全檢查）和步驟將幫助團隊獲得合規性與DevOps的融合之益。
作者：Sarah Goff-Dupont
譯者：半部春秋
“哎呀。真要命……”瑪麗亞關閉了另一個瀏覽器選項卡（上面有她不打算申請的另外一份公開招聘啓事），歇斯底里地吼道。她惱怒地一頭撞在桌子上，她之前壓根沒想到會像現在這般痛苦。天哪，究竟是怎麼回事？
她曾經熱愛的工作，如今變得面目可憎。她身處一個偉大的團隊，一個偉大的公司，並且擔任IT和工程主管的要職，她的轉角辦公室視野空闊，一眼就可以看到室外的美好景色。後來，SplinterTech上市了。她滿腦子都是她的團隊現在務必遵守的多如牛毛的規則（PCI，SOX，HIPAA），她滿以爲這一切都可以輕易搞掂。但實際上這幾天都做了些什麼？理想很豐滿，現實很骨感，目前的境況跟想象的完全不一樣。
寫那些含糊不清的文檔本身就已經足夠把人的魂兒劈成兩半兒了，更別提還有代碼評審。
（此處原文作者用的是drain a person’s soul in two releases。《哈利波特與混血王子》一集中引入了魂器的概念，就是把靈魂分成幾份來對付敵人，編者猜想，這大概是作者埋下的一個梗）。
她的團隊並不抵觸審查代碼，只是他們似乎無法有效地完成這一工作，這是代碼審計時所應承擔的責任，這還會危及SplinterTech的聲譽，甚至有可能砸了2500人的飯碗。
對，現實就是這樣：壓力實在太大了。
“哎，瞻前顧後有什麼用，能解決什麼問題呢？”瑪麗亞心想，“可以跳槽逃避這一堆麻煩事，但是，這種畏畏縮縮的行徑並不光明磊落，壓根不是我的風格。”她凝視着牆，牆上是裝裱得很精美的文憑；這些文憑提醒她，她多才多藝、風光無限，但這些東西對她毫無意義，無助於解決她目前的困境 。
……
與瑪麗亞相似的境遇比比皆是，並非孤例。合規性和根管治療一樣激動人心。從好的方面來看，它不需要承受根管治療那樣的痛苦。
您現在可能已經聽說過DevOps。您甚至也像我一樣認可“DevOps實際上可幫助團隊滿足合規性標準”這一觀點，因爲自動化不僅是DevOps的一個完整部分，而且是可以確保研發和部署實踐的可靠性、可重複性和可追溯性的一個非常有效用的方法。更何況，自動化加速了整個過程，這有助於您與競爭對手同樣快速（甚至更加快速）地往前推進。而DevOps強調文化的透明度，在需要進行代碼審計的時候，它會讓您受益。
我相信對於技術團隊來說，完成開發速度，透明度和開發紀律之間的融合是個穿針引線（threading the m-fing needle）的精細活兒，這種事兒不會一蹴而就，但是你可以按照“雖然不容易但是完全可行”的步驟達到目標。
步驟1：識別並記錄影響您的團隊的所有規則
這是常識，也正因爲如此，所以往往很容易被忽視。確保您的團隊成員和利益相關者知道您需要遵守什麼規則、您將如何着手處理與這些規則相關的合規性，以及在哪裏可以參考這個規則——畢竟大家不可能過目不忘、事無鉅細記得一清二楚。爲了避免“文檔版本地獄”（ 順便說一下，這也是一個專業術語），把這些規則信息全部記錄在維基頁面上，然後再鏈接到團隊門戶和Dashboard等地方。如果如果能做到以下這點就更好了：在頁面上將關鍵人員指定爲“觀察者”，每次頁面有信息更新時觀察者都會收到通知。
步驟2：把待辦事項自動化
一旦人們瞭解什麼是重要的內容，以及爲什麼如此重要，您就可以設置自動化，使合規性變得更爲容易。首先選擇可以從手動轉換爲自動化的重複性任務，通常有如下幾類：
合併請求（Pull requests）——雖然應該總是進行細緻的、人工的審查，但您可以自動化繁瑣的部分，如確保兩個或更多的審覈人員批准PR（Pull Request），並且確保不存在與該提交相關聯的失敗構建或測試運行。
代碼覆蓋率（Code coverage）——測試覆蓋率低於某個閾值時觸發失敗構建，隨便哪種說得過去的CI / CD工具都可以幹這個活。
連點成線（Connecting of dots）——確保代碼更改、代碼審查、構建結果、部署和事務卡片（issues）都鏈接在一起（這樣，您就可以通過單擊鼠標來從一個點到另一個點）。日事日畢更爲簡單，審計也更容易。
權限（Permissions ）——安全……自動化的確可能帶來安全問題。但您可以設置庫管理器，以便只有某些人可以在特定的代碼倉庫和/或分支中進行更改，並且沒有人可以在生產環境中實施變更。
注意：根據DevOps的原則，默認情況下，所有代碼倉庫和分支都應該開放只讀權限。而且，這種透明化更加簡單實用。
審計跟蹤（Audit trails）——通過自動記錄構建/測試和部署結果來形成完整的信息路徑。然後再鏈接代碼提交、評審和前文提到的事務卡片（issues）來完成閉環。
故障切換和恢復——自動回滾有問題的部署，比使用手動更不容易出錯。而且它是可追溯的，速度更快，這有助於您滿足服務級別協議（SLA）。
確保將此類工作納入每次迭代，這樣您就可以一點點的把他們溶入到日常工作中，並且不斷覆盤。“我們對分支的訪問控制是有效的還是矯枉過正？”……“我們的代碼覆蓋率是否讓審計員更加滿意？”……等等。訣竅在於履行您的義務而又不會自設藩籬。在這裏，還有一些穿針引線的事情要做。
步驟3：培養文化
平心而論，這應該是與步驟1和2同時發生的，因爲,在DevOps領域，文化始終是重中之重（但是，（如果在每一點都列示文化的重要性，編者注）這個“始終”會搞砸我漂亮的編號列表，就這樣吧）。
如果您的團隊缺乏溝通、互相指責和/或角色和責任不明確，簡單地把一些事情自動化就完事顯然毫無裨益。將您的團隊凝聚在一起，以確定您的問題所在，並弄清楚您將如何解決這些問題。聽起來很繁瑣困難，但不要恐慌、亂了分寸：《Atlassian團隊手冊》可以爲您提供幫助。
（手冊中有三個概念，健康監測器、場景和用例，以下爲便於理解，我們將三個部分添加了小標題，編者注）
團隊手冊的地址：https://www.atlassian.com/team-playbook/
場景（Plays）
透徹瞭解癥結所在以及爲何出現這些癥結的團隊，可以直接轉到手冊的場景（Plays）一欄，根據自己的痛點來選擇適合的場景。無論您是飽受“溝通障礙”之苦，抑或是深陷“領導力缺失症”，都沒有關係，《手冊》將提供一些方法技巧，讓您懸崖勒馬，重回正軌。
請記住，Plays不是額外的工作。它們只是以完全不同（以及有效）的方法來完成你本就該做的事情而已。
團隊健康監測器（Health Monitors）
然而，在許多情況下，一個團隊因爲不得而知的原因而功能失調。在這種情況下，團隊健康監測器（Health Monitors）應運而生。通過團隊健康監測器，您的團隊可以自我評估在高績效團隊中常見的八個屬性，並找出需要改進的地方。您還可以獲得有助於改進弱點的Plays建議。
用例（Game Plans）
爲便於實踐，《手冊》提供了一個專門用於構建DevOps文化的“Game Plan”—— “悲觀預測法” （Pre-mortem，假定最壞的情況發生，來考慮對策）或“約定規則”(Rules of Engagement，協同定義社交規範來促進團隊合作)等流行的Plays。Game Plan可以讓您少走一些彎路，但是您仍然應該使用健康監測器來了解您的團隊的工作。必須審慎對待。
最後，不要忘記，循序漸進的勝利也是來之不易的，值得爲之慶祝。 即使是“站會”上短暫的擊掌（ “代碼覆蓋率提高了20個百分點——很成功，Give me Five！”），都是可以保持勢頭，士氣高漲，創造奇蹟的籌碼。
（站會是敏捷開發的一種實踐，團隊成員用簡短的時間圍圈站立交流工作）
步驟3：培養文化
現在，您正在走上了團隊健康的正途，現在該開始改進工作流了。退一步，尋找可操作的快速進步。例如，對於團隊而言，比較常見的方法是，通過採用Git（或者偶爾採用Mercurial）實施DevOps來部署feature分支工作流。
關於如何更簡單輕鬆的切換到feature分支，這有一個免費教程
https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow
除非被證明可以進入生產環境，保持流程中所有雜亂無章的工作隔離孤立於某個feature分支，保證您不會出現“oh $#!τ”的時刻——例如，當您意識到您剛剛反格式化了生產日誌中的客戶數據，就是這樣的時刻。此外，您可以使用前文提到的權限自動化,從而更好地控制從分支到分支以及從環境到環境的變更流程。
還要檢查在所需要的地方是否達到了你所需要的代碼覆蓋率水平。“實例化需求規格” 方法在這裏大有可爲。根據這一方法的合規性進行工作，從而可以瞭解合規性失敗會是什麼樣子（比如，就如之前的生產日誌中客戶數據的顯示問題，事先定義日誌中數據的顯示方式），然後編寫一些測試代碼，一旦觸發了這些條件，這些測試代碼可以導致構建失敗。
一旦您有了健壯的自動化測試，您就有能力根據您所使用的特定規則，來將構建自動的推送到下一個環境。再次提醒：自動部署是您的良師益友。他們是可靠的和可追溯的——這兩個特點都是審計員所鍾愛的。
那麼，還有可以通過自動化來消除的其他一些開銷嗎？例如，如果您使用JIRA Software跟蹤您的工作，則可以將其與Bitbucket集成，以利用“智能提交”，自動將相關問題轉移到工作流的下一步，並節省了返回敏捷板（agile board）的步驟。或者您可以將存儲庫管理器與CI/CD工具集成，以便在創建pull request時自動觸發構建。
這是一個進程，而不是整個工作的顛覆。
您現在是不是有點頭暈目眩找不到方向？不要緊張。從邏輯視角，一事一議，不斷迭代，將使轉型過程更加易於管理。還記得本文開頭的瑪麗亞嗎？一步一個腳印的改善使得她的團隊回到正軌。如果說這很容易，那我是在自欺欺人。但他們做到了，現在他們溝通得很好，狀況大爲改觀。
爲了在技術方面提供幫助，請考慮切換到BitBucket Server或Bitbucket數據中心等Git倉庫管理工具。像您一樣身處管制行業的團隊，正在利用Bitbucket支持工作流的執行（如，要求綠色構建或代碼審查的多重審批）、項目級管理控制和細粒度權限功能。
如果您已經在使用Bitbucket服務器/數據中心（看看，您真是越來越上路了）並希望加強您的持續集成實踐，那麼，可以考察一下Bamboo。它具有一系列合規性-使能（compliance-flavored）的功能，如項目組織、權限，以及與Bitbucket服務器和JIRA軟件的深度整合。
一點點靈巧的工具作業，加上大量正確的文化和實踐，是享有DevOps方法的所有好處而不違反合規性規則的好方法。誰說魚和熊掌不能兼得呢？
原文鏈接：https://www.atlassian.com/blog/devops/how-to-make-compliance-easier-devops
關於作者：
莎拉是一位Atlassian敏捷交付傳道者，之前是一名測試自動化工程師，還是簡化書呆子式生活的忠實擁躉。例如，像持續集成和自動化一樣。手動測試越來越變得枯燥無趣，她試圖作出一些改變。她所崇拜的人包括瑪格麗特·撒切爾夫人、麥吉弗和她的母親。
關於EAWorld
微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微信號：EAWorld，長按二維碼關注。
