產品經理人的持續交付和DevOps實踐

時間 2019-11-11

標籤產品經理持續交付 devops 實踐简体版

原文原文鏈接

若是你正處於下列情形中，那這篇文章是爲你準備的：前端

你目前身處技術行業，你是產品經理，而且，你明白特性分支是什麼，CD表明什麼，DevOps文化是什麼樣子的。程序員
或者，你已經在實施敏捷，團隊每週都會與您的產品人員會面，討論故事和迭代。他們合做良好，他們此時構建的感受比以往任什麼時候候都要好。可是您的客戶仍然不能更快地獲取這些功能，你依舊要要等待版本發佈後才能使用。你可能已經據說過像Etsy，Flickr和Google這樣的公司，他們天天交付100次，但他們是如何作到的呢？服務器
又或者，你的開發團隊想要實現CI/CD，而且你也據說了一些美好的事情，你依舊關心期間的一些變數。那麼CD究竟是什麼呢？架構

讓咱們從一些定義和例子開始吧。微服務

Continuous Integration (CI)，持續集成工具

在傳統的軟件開發過程當中，整合過程一般在每一個人完成工做後，在項目結束時進行。整合一般須要數週或數月時間，極可能也會很是痛苦。持續集成是將整合階段提早到開發週期的一種作法，以便構建，測試和集成代碼更常常地發生。單元測試

持續集成意味着在不一樣的團隊成員間在不一樣的環境中分別爲相同的產品編寫軟件，並將它們的更改集成在一個稱爲源碼倉庫庫的地方。針各自編寫的零碎代碼構建組合成一個總體的軟件，並按照他們指望的方式工做。測試

開發人員常常採用一個被稱作持續集成服務器的工具爲他們作構建和集成的工做。持續集成要求團隊成員必須有能夠自測的代碼，這些代碼能夠驗證代碼如預期版的正常工做，這些測試被稱作單元測試。當代碼集成後全部的代碼單元測試經過，團隊將會獲得一個成功的構建結果。這代表他們驗證過了各自的變動被成功的集成到一塊兒，同時代碼如測試時預期的同樣工做着。雖然集成後的代碼成功的在一塊兒正常工做，但它沒有準備好上生產環境，由於它尚未在模擬生產環境中進行測試和驗證。你能夠在下面的連續交付部分中閱讀更多關於持續集成以後發生的狀況。網站

圖1編碼

爲了保持正確的持續集成實踐，團隊成員的代碼變動必須常常提交到主要的源代碼庫，並頻繁地集成和測試他們的代碼。一般是一小時屢次，但至少天天一次。CI的好處是使整合成爲非必要的事件。軟件一直處於被編碼和集成中。在CI以前，整合發生在建立過程的最後，只一次發生，而且花費了不肯定的時間; 如今有了CI，天天都會發生，而且僅須要幾分鐘。

Continuous Delivery (CD)，持續交付

咱們回到咱們的開發團隊，持續交付意味着每次對代碼進行更改時，都會集成和構建代碼，以便在與生產很是類似的環境中自動測試此代碼。一般，部署管道環境具備開發環境、測試環境和模擬生產環境，但這些階段因團隊、產品和組織而異。例如，咱們的Mingle團隊有一個叫作「Cupcake」的階段，它是一個模擬生產環境，而Etsy的模擬環境被稱爲「Princess」。

圖2

在每一個不一樣的環境中，編碼寫的代碼測試結果不一樣。這個過程對業務來講是很是有力的。這意味着，若是單元測試經過了全部的環境驗證，那麼你知道代碼在生產環境時極可能也會正常工做。一旦測試在全部環境中經過，您就能夠當即決定您的最終用戶是否得到最新的功能。並且，一旦您的開發人員完成構建，就能夠隨時爲客戶提供全新的、通過全面測試的工做軟件。

Continuous Deployment(CD)，持續部署

圖3

從上圖能夠清晰的看出，要實現持續部署，首先須要持續交付。持續交付的前提在CI的基礎之上，但最終是否應用到生產環境中去，仍是經過手動的方式來進行，持續部署真正實現了全自動部署更新發布。

DevOps

「DevOps」一詞來自「開發」和「操做」一詞的組合。 DevOps是一種促進開發人員和其餘技術專業人士之間的合做的文化，具體來講，在軟件交付和部署過程當中的溝通和協做，目標是更快速，更可靠地發佈更好的質量軟件。具備所謂DevOps文化的組織的共同特色是：自主多才技術團隊，高水平的測試和發佈自動化（持續交付）和共同目標多面手成員。

傳統方式的軟件交付過程以下：

圖4

採用持續交付部署路線後，演變成如下的方式，見下圖。

圖5

DevOps文化一般與持續交付相關聯，由於它們旨在增長開發人員和運營團隊之間的協做，而且使用自動流程來更快速、頻繁、可靠地構建、測試和發佈軟件。

題外話：此文是SUZIE PRINCE發佈在mindtheproduct網站上的文章，第一次嘗試着意譯過來，便於你們初識敏捷開發、持續部署及Devops之道，第一次翻譯不免有疏漏，還望各位見涼，點擊原文便可英文原版文章。