本文從開發流程角度分析了持續交付的實現,開發人員的溝通問題會拖延發布日期,必須客觀地觀察,才能瞭解成員之間的問題和流程缺陷,可視化的系統有助於找到問題所在,並在最短期內解決,使用工具或系統管理工做數據是有效提升效率的方式之一。工具
現在,許多企業組織都在實施持續交付的作法。但想要提升持續交付的效率,不少時候會以爲是在構建自動化測試和環境部署的時候出了問題,不過咱們認爲還有其餘因素致使咱們發佈軟件版本時有些壓力和阻礙,只是不肯定問題是什麼。測試
咱們開始觀察每個軟件版本發佈過程並記錄下看到的內容。例如,完成流程的每一個步驟所花費的時間,是人爲手動仍是自動化發佈,參與項目協做的人數有多少,以及發現致使新版本延遲發佈的問題。一旦咱們有足夠的數據,咱們就能夠開始分析它並尋找解決方式,這些會成爲咱們要解決的最重要的問題。優化
在觀察時保持客觀是很重要的,不要讓本身的偏見掩蓋實際發生的事實,特別是在嘗試改進項目流程和系統時很是有價值。插件
緣由是顯而易見的,在軟件版本發佈時經常不像咱們預計的那樣順暢,既不能無阻礙又沒法實現頻繁發佈,從而影響了咱們的交付能力。cdn
在改進的過程當中,能與技術專家共同合做能更快優化發佈流程。與專家合做的好處在於他們尊重數據和事實,而且也很是熱衷於讓事情變得更好。同時上文提到的收集了大量數據,就能夠顯示出咱們的問題,這意味着咱們專一於解決實際問題而不是假設。例如,數據顯示咱們在測試分段環境中部署的插件比咱們想象的要少得多,所以咱們就能夠垂手可得地處理這個阻止咱們輕鬆部署的問題。blog
若是某些改進真的很是重要,那在最快的時間內發佈是不可置疑的。問題在於,當咱們想要選擇本週的候選版本時,因爲各類緣由,團隊認爲須要包含最後一分鐘的「緊急」更改。這意味着推遲選擇發佈候選版本以及對發佈週期的連鎖效應,或者工做必須加班加點,即使趕在最後發佈了,有時也會影響版本質量。隊列
咱們開始有這樣的疑問,「爲何它必須在這個版本中出去?」,「若是咱們本週不發佈更改會怎麼樣?」或「它能等到下一個版本嗎?」。要獲取答案其實很是困難,由於對於團隊來講開發已是一個壓力很大的狀況,這些疑問的提出會被視做阻止他們進行更改。但事實上,當咱們試圖頻繁地發佈更改,更新迭代時,但實際上是能夠等待下一週時,它確實是違反了原則。由於咱們會忘記了一點,軟件版本發佈的關鍵是穩定。進程
經過討論並提出這些問題,咱們意識到有些變化根本不緊急,所以不須要趕工。這樣作的好處是咱們的版本更加順暢,須要修復錯誤的程序更少了,顯然發佈的壓力也減小了,而後咱們能夠更專一於如何進行週期性規律地發佈。資源
改變習慣是很難,由於習慣是長期這樣作的結果,但你必須努力中止舊習慣並用新習慣取而代之。選擇合適的時機發布能夠突出發現咱們的發佈週期中的問題,並有助於解決修復問題。開發
咱們能夠嘗試一些方法來幫助咱們養成良好的習慣。例如,若是參與發佈過程的人員將發送電子郵件做爲主要通訊方法的話,那通常會有數小時的延遲。必須瞭解到,在收件人閱讀並理解電子郵件以前,發件人其實尚未傳達任何信息。若是收件人正在開會,或者天天只會按期檢查電子郵件,那麼可能會延遲更久才能看到它。
爲了改變這種電子郵件習慣,咱們引入了一段時間的「物理提示」。在公衆區域設立一個項目展現板,在上面寫了候選版本號,每一個人均可以補充和查看,信息會像漣漪同樣擴散到全部人。那你就會知道整個發佈週期裏你的任務,以及目前的各任務進度。這也會激勵你趕忙去作任何你應該作的事情,這也有助於推進版本發佈流程。
展現板有另外一個好處,讓人們面對面交談,相互瞭解並開始感受像一個團隊。它幫助咱們下降了因溝通不順暢致使的流程拖延的風險,使咱們團隊合做,並幫助咱們造成了更好的溝通習慣。
總而言之,經過更有用的習慣來取代無效的習慣,展現板只是其中一個例子,你能夠找到更多適合的「好習慣」。同時,一旦找到好習慣,那麼就會造成行爲雪球,在滾動中不斷地變大,你甚至能夠在這個好習慣的基礎上再進行優化。若是你想了解更多,我強烈推薦能夠在網上搜索 Helen Lisowski 的「Good of Good(Agile)Habits」研討會。
當我第一次開始觀察發佈時,爲了改進它們,咱們可能不知道如何理解問題。這時候與經驗豐富的敏捷專家,精益和系統思想家合做的好處就顯現出來了。事實證實,個人整個觀察,收集數據和分析的方法,都應用科學思惟方式來理解問題的話會事半功倍。
如何應用科學的思惟方式來理解問題,包括你認爲接下來會發生什麼,並根據實際發生的事情調整你的後續步驟。它有四個主要步驟:
設定你的這次發佈的目的和內容,有哪些是挑戰,有哪些是平常。對咱們來講,大部分會是按需發佈,但這並不意味着咱們每分鐘都會發布,咱們能夠須要找到一種順暢無bug的方式發佈咱們想要的改進。
瞭解項目當前的開發進度和發佈情況。這就是收集和分析的數據的來源,咱們基本上有一個電子表格形式的價值流程圖。
創建階段性的小目標,即您的第一個里程碑。從你當前的狀態到你的最終目標每每是一個太大的跳躍,爲了取得進展,肯定一個更容易實現的中間目標是有幫助的。好比對咱們來講,能夠將發佈週期從15天減小到10天,而不是直接把目標定在3天。
肯定並執行以達到目的。這是一樣須要數據分析,數據向咱們展現了咱們最大的問題是等待發布的隊列時間過長。隊列是「死」時間,在此期間沒有任何事情發生,咱們只是在等待下一個過程發生。因此咱們就能夠將第一個改進重點放在減小或消除隊列時間上。
經過上面描述知道咱們要經過科學思惟方式來實現改變,這裏有一個例子,咱們嘗試將一個環境插件自動化安裝到咱們的測試板塊。這聽起來像是一個自動化過程,可是通過判斷後,咱們認爲它是破壞的構建,主要緣由是隻支持手動進行部署,那麼手動部署讓工做的效率下降,結合數據分析,手動部署會讓開發人員分心,致使發佈進度被延遲。因此爲了自動化流程 ,那必須延遲或者放棄這個環境插件的安裝。
目前運用工具來實現自動化進程是最快提高測試效率的一種辦法,市面上也有不少能實現自動化測試功能的工具或者平臺,國內有 EOLINKER,國外有POSTMAN 等等。因此對於在國內的環境,運用好的自動化工具,能幫你更好地實現項目運轉,提升開發測試效率。有興趣的點擊瞭解 EOLINKER。
顯而易見的好處是縮短了週期時間。週期爲10天,咱們兩週內不能發佈超過一次。在進行了幾回執行以後,固然咱們不會知足,繼續優化自動化交付,日後再減小一半,直到能夠在一天內發佈。
當對持續交付覆盤時,很容易只關注持續交付的技術部分,畢竟,這是大多數人和開發資源所關注的地方。可是,也請查看整個發佈週期,根據在項目自動化的流程和所需時間,找到在此期間其餘非技術因素阻礙了發佈。瞭解發佈週期流程中的全部步驟,找到問題並改進,再確保團隊的溝通方法有效併合做,纔能有助於實現持續交付。
參考資料:Sylvia MacDonald,Continuous Delivery - It’s Not All about Tech!