美好的周末又要來臨，小數就不跟大家聊沉甸甸的代碼了，讓我們輕松一下換個話題。今天的主角是産品經理，程式員史蒂夫、安妮和喬伊友情客串，報幕員兼跑龍套就是可愛的小數啦，接下來精彩馬上開始——
即使産品經理每周都在與開發團隊讨論新功能，團隊協作緊密無間，在不斷的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吧，祝大家周末愉快，下周見;)
原文連結：https://wanqu.co/amp/p/2862