 |
VOOZH | about |
|
VOOZH | about |
即使產品經理每周都在與開發團隊討論新功能，團隊協作緊密無間，在不斷的PUSH下，新功能比以往看起來上線和更新速度快多了。但換個角度，從用戶層面，其實仍然是一個緩慢的過程。那對比Flickr和Google這樣的公司能夠現在一天實現100次的更新疊代頻率，這到底是怎麼做到的呢？
毋庸置疑，這就是通過CI/CD在實際生產環境下帶來的好處和便利，作為產品經理， 對於CI/CD概念已經並不陌生，但即使想要通過它們來給現有產品更新帶來改變，仍然充滿擔憂顧慮和擔心。 那麼下面的內容，將幫助產品經理打消疑慮。
持續集成（ContinuousIntegration，CI）
在傳統軟件開發過程中，集成通常發生在每個人都完成了各自的工作之後。在項目尾聲階段，通常集成還要痛苦的花費數周或者數月的時間來完成。持續集成是一個將集成提前至開發周期的早期階段的實踐方式，讓構建、測試和集成代碼更經常反覆地發生。
持續集成意味著一個在家用筆記本編寫代碼的開發人員（嘿，史蒂夫）和另一個在辦公室編程的開發人員（嘿，安妮）可以為同樣的產品分別地編寫軟件，將其改動整合在一個叫做源存儲庫的地方。他們可以從各自編寫的部分構建出組合的軟件，並且按照他們期望的方式來測試軟件。
開發人員通常使用一種叫做ICServer的工具來做構建和集成。持續集成要求史蒂夫和安妮能夠自測代碼。分別測試各自代碼來保證它能夠正常工作，這些測試通常被稱為單元測試（Unit tests）。
代碼集成以後，當所有的單元測試通過，史蒂夫和安妮就得到了一個綠色構建（green build）。這表明他們已經成功地集成在一起，代碼正按照測試預期地在工作。然而，儘管集成代碼能夠成功地一起工作了，它仍未為生產做好準備，因為它沒有在類似生產的環境中測試和工作。在下面持續交付部分你可以了解到持續集成後面發生了什麼。
持續集成的好處是，集成不再是個頭疼事。軟件在一直被編寫和集成。在持續集成之前，集成發生在創建過程的結尾階段，一次性完成，並且不知道要耗時多久。而現在持續集成，每天都融入到了工作方式當中。
持續交付（Continuous Delivery，CD）
讓我們說回到我們的兩位開發人員，史蒂夫和安妮。持續交付意味著每次史蒂夫或安妮修改、整合和構建代碼時，也同時在類似於生產環境中自動測試了這段代碼。我們通常將這個在不同環境發佈和測試的過程叫做部署流水線。通常部署流水線有一個開發環境，一個測試環境，一個準生產環境，但是這些階段會根據不同的團隊、產品和組織而變化。例如，Mingle團隊有一個階段叫做「紙杯蛋糕」的准生產環境，而Etsy的准生產環境叫做「公主」。
持續學習
這個過程對於業務決策者來說非常重要。它意味著如果安妮的代碼通過了所有環境的測試，並將準備投入生產當中。你需要決定你的用戶是否立即能夠用上它。我們是否希望這個綠色構建現在投入生產？是的！一旦你的開發者完成了構建，那麼一個全新的、充分測試的、可以工作的應用已經為你的用戶準備好了。
持續部署（Continuous Deployment）
「DevOps」這個詞是「development」和「operations」的組合。DevOps已經上升為一種文化，它促使開發人員（史蒂夫和安妮你們快回來）和其他運維人員協同工作。具體地說，在軟件交付和部署的過程中溝通合作，為了能夠更快速更可靠地發佈質量更好的應用。
擁有DevOps文化的團隊通常有一個共同的特徵：熟練的多技能團隊（史蒂夫，安妮和喬伊都在同一團隊裏），高水平的測試和自動發佈（按持續交付的方式）以及團隊成員之間共同的目標。
你還將看到自動化的實踐對於持續交付和DevOps越來越重要。這是為了從持續交付和DevOps中實現可重複的、固定的和成功的應用發佈流程，來避免人工處理非常容易出錯、而且效率低下的問題。
接下來呢？
產品經理們已經逐步看到持續集成、持續交付和DevOps的諸多好處，那麼擁抱DevOps吧，祝大家周末愉快，下周見;)
