致產品經理： 持續整合、持續交付、持續部署和DevOps
美好的週末又要來臨，小數就不跟大家聊沉甸甸的程式碼了，讓我們輕鬆一下換個話題。今天的主角是產品經理，程式設計師史蒂夫、安妮和喬伊友情客串，報幕員兼跑龍套就是可愛的小數啦，接下來精彩馬上開始——
即使產品經理每週都在與開發團隊討論新功能，團隊協作緊密無間，在不斷的PUSH下，新功能比以往看起來上線和更新速度快多了。但換個角度，從使用者層面，其實仍然是一個緩慢的過程。那對比Flickr 和 Google這樣的公司能夠現在一天實現100次的更新迭代頻率，這到底是怎麼做到的呢？
毋庸置疑，這就是通過CI/CD在實際生產環境下帶來的好處和便利，作為產品經理， 對於CI/CD概念已經並不陌生，但即使想要通過它們來給現有產品更新帶來改變，仍然充滿擔憂顧慮和擔心。 那麼下面的內容，將幫助產品經理打消疑慮。
持續整合（Continuous Integration ，CI）
在傳統軟體開發過程中，整合通常發生在每個人都完成了各自的工作之後。在專案尾聲階段，通常整合還要痛苦的花費數週或者數月的時間來完成。持續整合是一個將整合提前至開發週期的早期階段的實踐方式，讓構建、測試和整合程式碼更經常反覆地發生。
持續整合意味著一個在家用筆記本編寫程式碼的開發人員（嘿，史蒂夫）和另一個在辦公室程式設計的開發人員（嘿，安妮）可以為同樣的產品分別地編寫軟體，將其改動整合在一個叫做源儲存庫的地方。他們可以從各自編寫的部分構建出組合的軟體，並且按照他們期望的方式來測試軟體。
開發人員通常使用一種叫做IC Server 的工具來做構建和整合。持續整合要求史蒂夫和安妮能夠自測程式碼。分別測試各自程式碼來保證它能夠正常工作，這些測試通常被稱為單元測試（Unit tests）。
程式碼整合以後，當所有的單元測試通過，史蒂夫和安妮就得到了一個綠色構建（green build）。這表明他們已經成功地整合在一起，程式碼正按照測試預期地在工作。然而，儘管整合程式碼能夠成功地一起工作了，它仍未為生產做好準備，因為它沒有在類似生產的環境中測試和工作。在下面持續交付部分你可以瞭解到持續整合後面發生了什麼。
考慮到實踐持續整合，史蒂夫和安妮必須頻繁地登記主程式碼倉庫、整合和測試他們的程式碼。通常一小時很多次，並且每天最少一次。
持續整合的好處是，整合不再是個頭疼事。軟體在一直被編寫和整合。在持續整合之前，整合發生在建立過程的結尾階段，一次性完成，並且不知道要耗時多久。而現在持續整合，每天都融入到了工作方式當中。
持續交付（Continuous Delivery，CD）
讓我們說回到我們的兩位開發人員，史蒂夫和安妮。持續交付意味著每次史蒂夫或安妮修改、整合和構建程式碼時，也同時在類似於生產環境中自動測試了這段程式碼。我們通常將這個在不同環境釋出和測試的過程叫做部署流水線。通常部署流水線有一個開發環境，一個測試環境，一個準生產環境，但是這些階段會根據不同的團隊、產品和組織而變化。例如，Mingle團隊有一個階段叫做“紙杯蛋糕”的準生產環境，而Etsy的準生產環境叫做“公主”。
在不同的環境下，安妮和史蒂夫寫的程式碼被分別進行測試。當代碼部署到生產環境它就開始了工作，這給予了他們更多的信心。並且只有當代碼通過前一個環境的測試才會進入到下一個部署流水線的環境當中去。通過這種方式，安妮和史蒂夫將會從每個環境中測試並得到新的反饋，如果有失敗，他們也可以在程式碼被應用到生產環境之前更加容易地發現問題並且修正它。
持續學習
這個過程對於業務決策者來說非常重要。它意味著如果安妮的程式碼通過了所有環境的測試，並將準備投入生產當中。你需要決定你的使用者是否立即能夠用上它。我們是否希望這個綠色構建現在投入生產？是的！一旦你的開發者完成了構建，那麼一個全新的、充分測試的、可以工作的應用已經為你的使用者準備好了。
持續部署（Continuous Deployment）
史蒂夫或者安妮所做的每個改動，都是通過測試環節，然後自動投入生產的實踐過程。關於這個概念這個PDF有一個很棒的闡釋：（http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf）。 為了達成持續部署，你首先需要持續交付，所以這不是決定哪個優先順序更高的二選一。無論如何，持續交付對於業務的決策帶來更大的敏捷性，這才是真正實現業務導向的捷徑。
開發運維（DevOps）
“DevOps”這個詞是“development”和“operations”的組合。DevOps已經上升為一種文化，它促使開發人員（史蒂夫和安妮你們快回來）和其他運維人員協同工作。具體地說，在軟體交付和部署的過程中溝通合作，為了能夠更快速更可靠地釋出質量更好的應用。
擁有DevOps文化的團隊通常有一個共同的特徵：熟練的多技能團隊（史蒂夫，安妮和喬伊都在同一團隊裡），高水平的測試和自動釋出（按持續交付的方式）以及團隊成員之間共同的目標。
一種方式是我們的開發朋友史蒂夫和安妮將同運維人員喬伊一起工作將應用交付給生產，而不是隻將他們的程式碼“移交”給喬伊來發布。同樣地，史蒂夫、安妮和喬伊都將作為共同負責所有產品支援和維護的服務團體的一部分，而不是僅由運維團隊負責支援。
你還將看到自動化的實踐對於持續交付和DevOps越來越重要。這是為了從持續交付和DevOps中實現可重複的、固定的和成功的應用釋出流程，來避免人工處理非常容易出錯、而且效率低下的問題。
DevOps文化通常和持續交付關聯起來，因為他們的目標都是為了提升開發團隊和運維團隊之間的協作效率，都使用自動化程序來更快速、更頻繁、更可靠地構建、測試和釋出應用。這正是我們想要的。
接下來呢？
產品經理們已經逐步看到持續整合、持續交付和DevOps的諸多好處，那麼擁抱DevOps吧，祝大家週末愉快，下週見;)