[TOC] > 交付管道的建立和自動化是持續交付的基礎 ## 持續集成 更關注代碼質量。持續集成是為了確保隨著需求變化而變化的代碼，在實現功能的同時，質量不受影響。因此，在每一次構建后會運行單元測試，保證代碼級的質量。單元測試會針對每一個特定的輸入去判斷和觀察輸出的結果，而單元測試的粒度則用來平衡持續集成的質量和速度。 持續集成的核心價值在于[1](http://growth.phodal.com/#fn1)： 1. 持續集成中的任何一個環節都是自動完成的，無需太多的人工干預，有利于減少重復過程以節省時間、費用和工作量； 2. 持續集成保障了每個時間點上團隊成員提交的代碼是能成功集成的。換言之，任何時間點都能第一時間發現軟件的集成問題，使任意時間發布可部署的軟件成為了可能； 3. 持續集成還能利于軟件本身的發展趨勢，這點在需求不明確或是頻繁性變更的情景中尤其重要，持續集成的質量能幫助團隊進行有效決策，同時建立團隊對開發產品的信心。 ### 持續集成系統 在前面的內容里，我們已經介紹了持續集成的各項基礎設施——如使用版本管理、編寫測試、自動化部署。要構建這樣的一個持續集成系統需要下面的內容： * 支持自動構建 * 源碼服務器 * 持續集成服務器 我們已經實現了前兩點，針對于第三點——持續集成服務器，我們可以以 Jenkins 為例做一些簡單的說明。它是一種基于 Java 開發的持續集成工具，并提供了用于監控持續重復工作的軟件平臺。 它可以讓整個開發流程到部署都實現自動化。由于每個功能可以一點點的加在 build 中，那么這樣就能保證每次的新 build 可以交付新的功能。同時，我們可以根據用戶的反饋情況及時調整開發方向，降低項目風險。 ### 持續集成流程 我們就可以對這個工作流展開進入介紹。持續集成重要就是要保證整個過程是**可持續**的。如下圖是一個持續集成的工作流：  CI Workflow 不同的開發者在自己的機器上開發功能代碼。在完成一定的本地提交后，這些代碼將會提交給源代碼控制服務器。不過，在那之前我們應該在本地跑測試來減少持續集成失敗的情況。接著，我們的CI會定時去獲取源碼服務器是否有代碼修改。如果有代碼修改，那么我們的集成服務器將會獲取這些代碼。然后，構建這個項目，運行測試，再輸出返回結果。最后，我們可以開發一些小工具來提醒用戶 CI 是否運行成功。 如果這個過程中，我們我們的 CI 運行失敗的話，那么我們就不能再提交新的代碼——除了修復 CI 的代碼外。持續集成變紅不能過夜，要么快速解決，要么回退。 在這個過程中，有兩點值得注意，一個是小步前進，一個是遲早反饋。 #### 小步前進 小步前進是一系列步驟的集合，其目的是：集成越早問題越小。即當我們的代碼越早的提交到源碼服務器，那么其他人就可以盡可能早的和我們的代碼集成到一起。這也意味著，每天結束時，我們在本地的修改要盡可能小，并且這些修改還要保證不會破壞持續集成。 我們需要頻繁地在本地提交我們的代碼，編寫獨立的測試——如果我們在最后才編寫測試，這會拖慢整個流程，它使得我們不能盡可能早的提交代碼。 #### 盡早反饋 > 反饋越早，那么問題越小。 無論是精益還是敏捷都在強調一點——盡早反饋，反饋對于提高敏捷開發流程效力非常重要。從日常的： * Code Review * 靜態代碼分析 * 自動集成測試 * 自動驗收測試 * 高頻率發布 我們都在做盡可能小的反饋，這些實踐對于我們完成一個好的持續集成來說是非常重要的基礎。 參考資料： -《持續交付：發布可靠軟件的系統方法》 ## 持續交付 持續交付依賴于一系列的工具和實踐，下圖是一個持續交付的工作流：  CD Workflow 還有一系列與開發無關的技能： 1. 自動化 2. DevOps 3. 云基礎設施 4. 以軟件為中心的哲學 ### 基礎設施 在我們使我們的項目可以持續交付軟件包的時候，我們需要 #### 本地開發環境 在本地編寫代碼時，我們需要設置本地的開發環境。假設我們要開始一個 Java Web 項目，在我們的開發機器上，我們需要安裝： * 版本管理工具，如 git，用于管理源代碼。 * IDE，如Intellij IDEA，用于搭建開發環境。 * 構建工具，如 gradle，用于安裝依賴、運行測試、構建工程等等。 * 語法檢測工具，如 checkstyle，用于檢查代碼語法。 * 單元測試框架，如 JUnit，用于進行單元測試。 * 集成測試框架，如 Cucumber、Selenium，用于做行為測試。 除此，在我們的項目代碼里，我們還需要： * `CI運行腳本`，用于在 CI 上運行指定的測試。 * `上傳包腳本`，用于上傳 build 完的軟件包。 * `部署腳本`，用于在本地部署包到測試環境。 * `監控代碼`，用于監測網站性能和用戶行為。 當然我們還需要輔助一些測試工具來測試網站，如性能測試、網絡測試等等。 #### 持續集成環境 為什么在這里會出現一個持續集成環境？我也不知道，只是想到了這里。由于我們需要持續集成，所以我們也需要一個運行持續集成服務器的機器。 持續集成服務器是由兩部分組成的：Master 和 Agent。即一個用于控制其他運行持續集成服務的機器，以及執行指令的機器。因此，我們需要在一臺機器上安裝 Master 軟件，在另外一臺機器上作為 Agent。在我們的 Agent上，我們需要安裝相對應的運行服務的軟件，如 * 指定版本的語言環境 ，如Java、Python。 * 構建工具。 * 版本管理工具，及對應的密鑰。 * 打包工具，如 RPM。 * 虛擬桌面，即可以模擬桌面瀏覽器的軟件。 同時，我們還需要有一個地方放置我們的RPM包。 #### 測試環境 相比于上面兩個環境來說，測試環境就比較簡單了。我們只需要創建幾個不同的環境，即開發者的測試環境、QA 環境、模擬線上環境，在這幾個不同的環境上有不同的配置。 ### 持續部署 在持續交付之外的，還有持續部署——這個就更依賴于團隊的組織結構了。其與持續交付的對比如下圖所示：  持續部署 我們可以從圖中看到，兩者的最大不同之處在于：持續部署會直接將構建生成的部署到產品環境。這就意味著，我們不僅要有強大的技術實力，也要有足夠的組織支持才能做到。而這部分已經超出了軟件開發的內容了~~。 ## 持續學習 如果說`持續交付則是一種對卓越的追求`,那么`持續學習應該就是追求軟件卓越`。 如果說`持續集成是一種軟件開發實踐`,那么對于技術人員來說——`持續寫作應該就是持續學習的實踐` 生活總會遇到壓力，來自工作上的也好，來自對于技術上的興趣也罷，我們需要持續來斷地學習。沒有一直能立于不敗的方法，在傳說中的武林上也是如此。 對于持續學習來說，通常會有以下的 * 閱讀 * 編程 * 寫作 有意思的是持續學習有額外的好處便是 * 持續學習可以降低危機感 ### 持續閱讀 看過如此多的金庸、古龍小說我們都會發現有那么多的人都在追求武功上的卓越，有的走火入魔了，有的鋌而走險殺人放火，暫且不討論這些。我們簡單的以大部分的主角為例，大部分的主角自小就練得一手好武藝，少部分除外，而他們通過會比前輩厲害，只是因為我們看了前人的說，現在也是如此。 **20 年前要建一個淘寶怕是沒有兩三個月十幾個是不行的，但是今天要建出原來淘寶的模樣，也許一個人單槍匹馬一兩天就能搞定了，還能上線。** 有意思的是武林小說的武林秘籍少之又少，正常情況下能學到的或許就是教科書上的種種。而現在，如果我們要學習?`UX`?的話，我們很容易可以從亞馬遜上拿到一個書單，又或者是某個博客里面列舉出來的:《用戶體驗要素》、《交互設計沉思錄》、《怦然心動——情感化交互設計指南》等等。 我們可以更加方便快捷地獲取我們所需要的知識從書上、網上等等。 `閱讀更多的書籍是持續學習的基礎。` 總會聽到有些人在工作之余看了更多的書，在某種情況下來說是有意義的。我們需要不斷地去閱讀。 ### 持續編程 編程算是一個開發人員工作時一直在做的，而對于工作之后來說，到底還會有多少人繼續編程就是一個有意思的問題。 對于一個有興趣的程序員來說，工作和興趣都是分開的，可以將工作視之為無味的東西，但是休息時間呢？可以用來創造自己覺得有意義的東西，可以用來認識更多志同道合的人，對于不滿現狀的人更是如此，或許為自己創造了更多的機會。 如果工作之后編程，不應該是為了工作而編程，應該為了興趣而編程，或者其他。如果沒有時間，是不是因為加班了，對于剛開始養家糊口來說加班是沒有辦法的，但是如果不是的話，又沒時間，是不是…… ### 持續寫作 對于一個技能人員來說，寫作可能不是一件有意思的事，但是也不是一件很難的事，沒有必要將大量的文字用文本表示。寫給其他技術人員看的，有時候更多的是代碼、思路、圖。寫作對于學習的意思怕是有一大把，寫作是最好的輸入，也是最好的輸出。你需要為你的這篇文章 * 去參考更多的資料 * 更深入的學習 * 更多的時間付出 然而這些都是有價值的，你也許可以從中得到 * 一份工作 * 一些志同道合的朋友 * 一個博客 * 一種習慣 * 還有人生 * 或許還能寫書。 對于我來說，更多的是對于`讀者`和?`SEO`?的興趣，SEO 是一門藝術。