本文來源： about.gitlab.com
作者： Valerie Silverthorne
譯者： 極狐(GitLab) 市場部內容團隊

CI/CD 是 DevOps 成功實踐的核心，想要實現現代化應用程序開發的團隊，必須遵從 CI/CD 最佳實踐。如何確保團隊正確使用 CI/CD？以下內容供你參考。

CI/CD 是什麼？

CI/CD 既是技術流程，又是一種思想，還是一系列步驟......CI/CD 包括以上全部內容。簡而言之，CI/CD 能讓 DevOps 團隊通過自動化來簡化代碼提交。

• CI（持續集成） 簡化了軟件構建和源代碼集成，實現版本控制，並通過自動化促進良好協作；
• CI 結束後，持續交付（CD）開始自動化測試和部署。CD 不僅減少了花費在交付和部署過程中因手動操作所帶來的諸多弊端，還能夠讓團隊在管理軟件生命週期方面，極大減少所使用的工具數量。

CI/CD 有哪些最佳實踐？

如果想用 CI/CD 來獲得成功，那就讓持續集成、持續交付及持續部署成為團隊的習慣，因為它們是軟件研發實踐的基石。DevOps 的目標就是更快將軟件交付給用户，而 CI/CD 實踐將讓這一切變為現實。

如果問 10 個 DevOps 團隊的 CI/CD 實踐，會得到 10 個不同答案。但以下幾個方面都是大家一致推崇的：

1. 只構建一次： 不要為每個階段創建一個新構建，這會帶來不一致風險。在 CI/CD 流水線中，推薦使用同一個構建制品（與環境無關的構建）；
2. 簡化測試： 在測試覆蓋率和性能之間取得平衡。如果花費很長時間才能出現測試結果，用户則會試圖繞開這些流程；
3. 快速失敗： 在 CI 側，提交代碼的研發人員需要儘快得知他們提交的代碼是否有問題，以便還能在熟悉這些代碼的時候快速回滾和修復。“快速失敗” 理念幫助開發人員減少上下文切換，讓 DevOps 專業人員更加快樂；
4. 每天提交： 代碼提交越規律，DevOps 團隊將能看到越多價值；
5. 有問題就修復： CI/CD 讓修復失敗構建變得更加簡單；
6. 清空預生產環境： 環境持續運行時間越長，越難追蹤應用在環境上的配置變更和更新。在每次部署之間都清空預生產環境是好習慣；
7. 始終自動化： 不斷調整 CI/CD 流水線以確保實現持持續自動化；
8. 明確步驟： 確保版本發佈和回滾計劃明確寫進文檔，並被整個團隊理解；
9. 保持安全： CI/CD 是一種左移，因此它提供了一個很好的機會，將安全集成到早期流程中；
10. 反饋循環： 確保整個團隊有一個簡單辦法來接受（或者貢獻）反饋。

深入研究 CD 的最佳實踐

CD（持續交付/部署）也值得深入研究一下它們的最佳實踐，儘管風頭總是被 CI 搶走了。以下是 CD 的最佳實踐：

• 立即開始： 不要等新平台，從現有的開始調整，讓它們變得更快、更高效；
• 少即是多： 最好的 CD 是用最少的工具完成的；
• 追蹤正在發生的事情： Issue 和 Merge Request 可能會失控，但 Milestone 可以提供幫助的，例如在設置敏捷衝刺和發佈時，Milestone 具有雙重作用：幫助跟蹤正在進行的所有事項；進行有計劃的交付；
• 自動化部署變更： 通過自動化簡化用户驗收測試和 staging 環境部署；
• 管理髮布流水線： 自動化一切；
• 建立監控： 密切關注生產流程能夠節約時間和金錢,還能夠對業務側提供關鍵數據；
• 啓動持續部署： 一旦啓動持續交付，就把手從部署上拿開，通過自動化將變更部署到生產環境。

如何改進 CI/CD 流水線？

所謂流水線，其實只是一種描述部署新版本軟件所涉及到的一系列步驟的方式。監控和自動化被引入到 CI/CD 中，用以改進應用程序開發流程，特別是在集成和測試階段，以及軟件交付和部署階段。

一個典型的 CI/CD 流水線應具有這些元素：計劃、分析、設計、構建、測試、發佈、部署、驗證、合規及維護。這些步驟都可以手動實現，但是 CI/CD 流水線的價值體現在自動化。

如果要微調 CI/CD 流水線，可以考慮通過以下幾點來增強性能：

• 混合發佈策略。 金絲雀發佈（或金絲雀部署）或許值得考慮。在金絲雀發佈中，只有特定用户羣體能看到新功能特性部署。
• 增加更多自動化測試，因為自動化測試用不嫌多。
• 持續做減法。 更少的工具意味着更少的手動操作和步驟。如果 CI/CD 是 DevOps 平台的一部分，那麼一切都應該在一個平台上。
• 將軟件組件分析視為常規實踐，以確保 DevOps 團隊持續追蹤重要的開源軟件問題。

如何衡量 CI/CD 是否成功？

DevOps 團隊可能不知道他們的 CI/CD 實踐運行如何，除非能夠衡量它們。指標在改進系統性能及幫助識別何處可以增加價值時，扮演了非常重要的角色，還為任何改進的影響提供了基準。

以下是一些衡量 CI/CD 是否成功的指標：

➤ 循環週期

指從開始編寫代碼到推出功能特性需要的時間。

為計算出循環週期平均時長，需衡量研發流程整個階段。該指標提供總體開發時長以及過程瓶頸的洞察。

➤ 價值實現時間

指發佈編寫的代碼需要多長時間。集成、測試、交付及部署應該需要幾分鐘到幾小時才能完成測試周期。如果 CI/CD 流水線的構建需要數天才能完成，則無法實現價值，需要對整個流程進行調整。

➤ 持續運行時長

正常運行時長是對穩定性及可靠性的一種衡量，這是運維團隊首要任務之一。

當 CI/CD 策略自動化時，運維負責人就可以將更多時間聚焦在系統穩定性上，而在工作流問題上花費更少時間。

➤ 錯誤率

應用程序錯誤率是研發過程中的一個既定事實。追蹤錯誤率非常重要，因為錯誤率不僅能夠指出質量問題，還可以指示連續的性能問題以及與正常運行時間有關問題。

如果持續運行時長和錯誤率都很高，説明開發團隊和運維團隊之間存在常見的 CI/CD 挑戰。

➤ 基礎設施成本

在雲原生開發中，基礎設施成本非常重要。如不加以控制，部署和管理一個 CI/CD 平台會帶來巨大成本。為了確定它們如何定價，雲廠商將考慮網絡硬件、基礎設施維護及人力成本。

➤ 團隊留存率

眾所周知：當開發人員或者任何一個人真切感受到自己的價值和被重視的時候，他們會留下來。

當團隊默契協作，那麼留存是必然結果。相反，開發者合作不順暢、進展緩慢等，他們可能會感到不舒服。通過查看團隊留存率，可以發現潛在問題。

遵循 CI/CD 最佳實踐有哪些收益？

當遵循最佳實踐時，CI/CD 的好處會貫徹整個組織：

從 HR 到運維，團隊能夠更好的工作並達到最終目的；圍繞 CI/CD 性能建立指標不僅可以提供有關開發的洞察，還可以延伸到業務的諸多方面；一個功能良好的 CI/CD 流水線能夠改變 DevOps 團隊的遊戲規則。

以下是一些巨大的優勢：

開發人員不是在修東西，而是在寫代碼。 越少的工具和工具鏈意味着在工具維護上花更少時間，從而將更多時間用於在生產高質量軟件。

代碼即生產。 不要讓代碼排隊等待，而應該立馬進入真實世界。這能讓開發人員收到及時反饋的成就感。

開發人員可以專注於解決業務問題。 簡化的 CI/CD 流水線能夠讓開發者真正聚焦在重要的事情上，而不是讓問題代碼、繁瑣的手動操作、生產問題等其他事項來分散注意力。

更容易創新。 這是一個充滿競爭的世界，組織需要所有可用的工具來勇立潮頭。一個構建良好的 CI/CD 流程能夠讓軟件研發更容易、更快和更安全，這也意味着 DevOps 團隊有更多時間和精力去創新。

吸引並留下人才。 人力市場的競爭激烈，DevOps 人才難以被打動。與其畫大餅説 “我們很重視 DevOps 團隊”，不如圍繞 CI/CD 流程和技術來進行一些實際投資。

每一個人發揮所長。 CI/CD流水線幫助研發、運維、安全以及測試各司其職，發揮所長。

CI/CD 部署策略

請記住，CI/CD 的目標是更快、更好地將軟件交付到客户手中，提高生產力。訣竅在於採用在企業內部行之有效的部署策略。以下是一些讓 CI/CD 成功的策略：

• 頻繁提交代碼；
• 自動化構建流程；
• 並行運行測試，並構建一個部署流水線；
• 快速失敗並且採取左移措施，為開發人員提供技能和工具，以便在不破壞整體流程的基礎上實現加速；
• 使用能夠快速獲得反饋的 CI 工具。

如何在組織中實施 CI/CD？

在實施任何軟件之前，關鍵是要確定業務驅動因素是什麼，採用 CI/CD 也是如此，所有研發相關者都應該儘早參與實施過程。研發人員應該提供意見，因為他們將是產品的主要用户。

雖然這看起來有違直覺，因為 CI/CD 是以自動化方式加速軟件交付的步伐，但是需要以緩慢而平穩的心態開始整個過程。

在集成過程中保持一致性很重要。執行單元測試、手動發版以及追蹤指標。然後決定什麼可以自動化、什麼應該自動化。