即使產品經理每周都在與開發(fā)團隊討論新功能，團隊協(xié)作緊密無間，在不斷的PUSH下，新功能比以往看起來上線和更新速度快多了。但換個角度，從用戶層面，其實仍然是一個緩慢的過程。那對比Flickr 和 Google這樣的公司能夠現(xiàn)在一天實現(xiàn)100次的更新迭代頻率，這到底是怎么做到的呢？

毋庸置疑，這就是通過CI/CD在實際生產環(huán)境下帶來的好處和便利，作為產品經理， 對于CI/CD概念已經并不陌生，但即使想要通過它們來給現(xiàn)有產品更新帶來改變，仍然充滿擔憂顧慮和擔心。 那么下面的內容，將幫助產品經理打消疑慮。

持續(xù)集成（Continuous Integration ，CI）

在傳統(tǒng)軟件開發(fā)過程中，集成通常發(fā)生在每個人都完成了各自的工作之后。在項目尾聲階段，通常集成還要痛苦的花費數(shù)周或者數(shù)月的時間來完成。持續(xù)集成是一個將集成提前至開發(fā)周期的早期階段的實踐方式，讓構建、測試和集成代碼更經常反復地發(fā)生。

持續(xù)集成意味著一個在家用筆記本編寫代碼的開發(fā)人員（嘿，史蒂夫）和另一個在辦公室編程的開發(fā)人員（嘿，安妮）可以為同樣的產品分別地編寫軟件，將其改動整合在一個叫做源存儲庫的地方。他們可以從各自編寫的部分構建出組合的軟件，并且按照他們期望的方式來測試軟件。

開發(fā)人員通常使用一種叫做IC Server 的工具來做構建和集成。持續(xù)集成要求史蒂夫和安妮能夠自測代碼。分別測試各自代碼來保證它能夠正常工作，這些測試通常被稱為單元測試（Unit tests）。

代碼集成以后，當所有的單元測試通過，史蒂夫和安妮就得到了一個綠色構建（green build）。這表明他們已經成功地集成在一起，代碼正按照測試預期地在工作。然而，盡管集成代碼能夠成功地一起工作了，它仍未為生產做好準備，因為它沒有在類似生產的環(huán)境中測試和工作。在下面持續(xù)交付部分你可以了解到持續(xù)集成后面發(fā)生了什么。

考慮到實踐持續(xù)集成，史蒂夫和安妮必須頻繁地登記主代碼倉庫、集成和測試他們的代碼。通常一小時很多次，并且每天最少一次。

持續(xù)集成的好處是，集成不再是個頭疼事。軟件在一直被編寫和集成。在持續(xù)集成之前，集成發(fā)生在創(chuàng)建過程的結尾階段，一次性完成，并且不知道要耗時多久。而現(xiàn)在持續(xù)集成，每天都融入到了工作方式當中。

持續(xù)交付（Continuous Delivery，CD）

讓我們說回到我們的兩位開發(fā)人員，史蒂夫和安妮。持續(xù)交付意味著每次史蒂夫或安妮修改、整合和構建代碼時，也同時在類似于生產環(huán)境中自動測試了這段代碼。我們通常將這個在不同環(huán)境發(fā)布和測試的過程叫做部署流水線。通常部署流水線有一個開發(fā)環(huán)境，一個測試環(huán)境，一個準生產環(huán)境，但是這些階段會根據不同的團隊、產品和組織而變化。例如，Mingle團隊有一個階段叫做“紙杯蛋糕”的準生產環(huán)境，而Etsy的準生產環(huán)境叫做“公主”。

在不同的環(huán)境下，安妮和史蒂夫寫的代碼被分別進行測試。當代碼部署到生產環(huán)境它就開始了工作，這給予了他們更多的信心。并且只有當代碼通過前一個環(huán)境的測試才會進入到下一個部署流水線的環(huán)境當中去。通過這種方式，安妮和史蒂夫將會從每個環(huán)境中測試并得到新的反饋，如果有失敗，他們也可以在代碼被應用到生產環(huán)境之前更加容易地發(fā)現(xiàn)問題并且修正它。

持續(xù)學習

這個過程對于業(yè)務決策者來說非常重要。它意味著如果安妮的代碼通過了所有環(huán)境的測試，并將準備投入生產當中。你需要決定你的用戶是否立即能夠用上它。我們是否希望這個綠色構建現(xiàn)在投入生產？是的！一旦你的開發(fā)者完成了構建，那么一個全新的、充分測試的、可以工作的應用已經為你的用戶準備好了。

持續(xù)部署（Continuous Deployment）

史蒂夫或者安妮所做的每個改動，都是通過測試環(huán)節(jié)，然后自動投入生產的實踐過程。關于這個概念這個PDF有一個很棒的闡釋：（http://www./2010/06/trunk/alwaysshiptrunk.pdf）。為了達成持續(xù)部署，你首先需要持續(xù)交付，所以這不是決定哪個優(yōu)先級更高的二選一。無論如何，持續(xù)交付對于業(yè)務的決策帶來更大的敏捷性，這才是真正實現(xiàn)業(yè)務導向的捷徑。

開發(fā)運維（DevOps）

 “DevOps”這個詞是“development”和“operations”的組合。DevOps已經上升為一種文化，它促使開發(fā)人員（史蒂夫和安妮你們快回來）和其他運維人員協(xié)同工作。具體地說，在軟件交付和部署的過程中溝通合作，為了能夠更快速更可靠地發(fā)布質量更好的應用。

擁有DevOps文化的團隊通常有一個共同的特征：熟練的多技能團隊（史蒂夫，安妮和喬伊都在同一團隊里），高水平的測試和自動發(fā)布（按持續(xù)交付的方式）以及團隊成員之間共同的目標。

一種方式是我們的開發(fā)朋友史蒂夫和安妮將同運維人員喬伊一起工作將應用交付給生產，而不是只將他們的代碼“移交”給喬伊來發(fā)布。同樣地，史蒂夫、安妮和喬伊都將作為共同負責所有產品支持和維護的服務團體的一部分，而不是僅由運維團隊負責支持。

你還將看到自動化的實踐對于持續(xù)交付和DevOps越來越重要。這是為了從持續(xù)交付和DevOps中實現(xiàn)可重復的、固定的和成功的應用發(fā)布流程，來避免人工處理非常容易出錯、而且效率低下的問題。

DevOps文化通常和持續(xù)交付關聯(lián)起來，因為他們的目標都是為了提升開發(fā)團隊和運維團隊之間的協(xié)作效率，都使用自動化進程來更快速、更頻繁、更可靠地構建、測試和發(fā)布應用。這正是我們想要的。

接下來呢？

產品經理們已經逐步看到持續(xù)集成、持續(xù)交付和DevOps的諸多好處，那么擁抱DevOps吧，祝大家周末愉快，下周見：)