根據IDC最近的一項研究，全球DevOps軟件市場在2017年達到29億美元，預計到2022年將達到66億美元。隨著去年超過50%的組織採用DevOps，
持續集成(CI)和持續交付(CD)已經成為軟件開發過程中不可或缺的一部分。PlusMode · 使用可視化工具快速構建應用程序 基於大數據與拖拽式產品工具自動關聯項目組件，並幫助項目快速落地
APICloud企業IT敏捷項目管理工具
APICloud需求分析工具
本文，我們將重點討論CI / CD最佳實踐，無論企業正在處於DevOps的哪個階段，這些實踐都有助於加速DevOps採用。
從最初的瀑布模型，到後來的敏捷開發，再到今天的 DevOps， 這是現代開發人員構建出色產品的技術路線。隨著 DevOps 的興起，出現了持續集成，持續交付（CI/CD）和持續部署的新方法， 而傳統的軟件開發和交付方式在迅速變得過時。過去的敏捷時代裡， 大多數公司的軟件發佈週期是每月、每季度甚至每年， 而在現在 DevOps 時代，每週、每天甚至每天多次都是常態。
我們為什麼要實踐DevOps？持續集成注重將各個開發者的工作集合到一個代碼倉庫中，通常每天會進行幾次， 主要目的是儘早發現集成錯誤，使團隊更加緊密結合，更好地協作。
持續交付的目的是最小化部署或發佈過程中團隊固有的摩擦，它的實現通常能夠將構建部署的每個步驟自動化，以便任何時刻能夠安全地完成代碼發佈（理想情況下）。 持續部署是一種更高程度的自動化，無論何時代碼有較大改動， 都會自動進行構建／部署。持續集成和持續交付是指在以自動化為基礎的構建-配置-部署-測試-發佈的短週期內開發和交付軟件的過程。簡而言之，我們使用CI/CD來高頻且可預測地交付更高質量的軟件。
持續集成（CI）在軟件開發中已經無處不在。因此，作為開發的基礎，CI成為DevOps組織中的關鍵實踐不足為奇。通過持續集成，開發人員能夠頻繁地將其代碼集成到公共代碼倉庫的主分支中。開發人員能夠在任何時候多次向倉庫提交作品，而不是獨立地開發每個功能模塊並在開發週期結束時一一提交。通過讓開發人員更快、更頻繁的做到這一點，從而降低了集成的開銷。在實際情況中，開發人員在集成時經常會發現新代碼和已有代碼存在衝突。如果集成較早並更加頻繁，那麼衝突將更容易解決且執行成本更低。
持續部署（CD）實際上是 CI 的擴展，將軟件交付流程進一步自動化，以便隨時輕鬆地部署到生成環境中。在這樣的流程中， 不需要人為決定何時及如何投入生產環境。CD從CI的開發、構建、單元測試、靜態代碼分析(SCA)和靜態分析安全測試(SAST)開始。最終，軟件交付流程將自動化擴展到功能、集成、性能和安全測試，以及配置管理和部署。這些是自動化的關鍵要素，在DevOps環境中，它們是必不可少的。我們甚至可以說，如果不做持續部署（CD），那麼你就做不好DevOps。為什麼？採用持續部署的組織可以將新功能快速傳遞給用戶，得到用戶對於新版本的快速反饋，並且可以迅速處理任何明顯的缺陷。 用戶對無用或者誤解需求的功能的快速反饋有助於團隊規劃投入，避免將精力集中於不容易產生回報的地方。企業不會在一夜之間完成DevOps轉變，這是一個持續改進的過程，當你掌握了一個最佳實踐的時候，還會有新的實踐出現，我們目標是更好的交付軟件。DevOps 8個CI/CD最佳實踐
1、採取“安全第一”的方法在一個漏洞和脆弱性持續給各種規模和能力的企業造成巨大聲譽和財務損失的世界裡，再怎麼強調安全的必要性都不為過。
由於CI / CD系統可以訪問代碼庫和憑據以在各種環境中進行部署，因此它通常會被作為主要目標。回想一下臭名昭著的優步入侵事件，黑客侵入了嵌入在GitHub軟件庫中的AWS憑證，竊取了5700萬用戶和60萬司機的個人信息。
為了實現自動化的目的，將憑證存儲在私有存儲庫中當然並不少見。因此，我們需要考慮隔離CI / CD系統，並將其放置在安全的內部網絡中。強大的雙因素身份驗證、身份和訪問管理系統將幫助您執行最小特權原則，並限制暴露於威脅。例如，將代理容器化並將其放置在安全網絡上。此外，我們還應該確保從開始到結束都將安全性考慮到開發過程中。這通常被稱為DevSecOps。
2、評估企業微服務架構
為了有效地實現DevOps，微服務架構是最好的方法。然而，重新架構現有應用程序可能是一項艱鉅的任務，可以考慮使用增量方法來維護任務關鍵型系統，並圍繞其構建新架構。這將有助於逐步用新的體系結構替換舊的系統。
3、執行跟蹤和版本控制工具
像Jira和Bugzilla這樣的工具可以幫助您更好地瞭解軟件的進展，並輕鬆地與分佈式團隊協作。像Git這樣的版本控制系統，它可以為團隊創建“單一事實來源”，允許跟蹤代碼庫中的更改，並且在需要回滾時提供幫助。通過允許團隊協作並將更改集成到共享存儲庫中，GitOps可以顯著提高MTTR。
4、每日提交，避免分歧
減少分歧的目標是花更多的時間在開發上，花更少的時間在版本控制上。然而，要充分利用GitOps，開發人員應至少每天一次直接提交到主分支或合併其本地分支中的更改。這將迫使開發人員處理更小，更小規模的集成難題，而不是在發佈前將許多分支合併到主幹中時發生的大規模集成難題（以及相關的返工）。
5、只生成一次
消除重複構建源代碼的做法，即使必須構建、打包或捆綁軟件，也應該只執行一次該步驟並升級二進制文件。大多數成功的CI實施都將構建過程作為CI / CD循環的第一步，以將軟件打包在乾淨的環境中。這消除了疏忽，並減少了以後隨時引入或遺漏錯誤的機會。此外，每次都應對生成的工件進行版本控制並將其上載到Git，這樣無論何時提取它，構建都不會發生變化。
6、確定首先自動化哪些流程和測試
儘管採用漸進式自動化方法聽起來不錯，但是從手動過程過渡到自動化過程的組織經常發現很難決定首先自動化哪些過程。例如，首先將編譯代碼的過程自動化是有益的。由於開發人員需要每天提交代碼，所以進行自動冒煙測試是有意義的。單元測試通常首先自動化，以減少開發人員的工作量。
因此，可以自動化功能測試，然後是UI測試。功能測試通常不需要在自動化腳本中頻繁更新，不像UI測試需要頻繁更改。其主要思想是考慮所有可能的依賴關係，並評估它們的影響，，以合理地確定自動化的優先級。
7、經常釋放
頻繁的發佈只有在軟件處於準備發佈狀態並且已經在類似生產的環境中測試過它的情況下才可能。這就是為什麼最佳實踐是在發佈之前添加一個與生產環境非常相似的部署階段。一些發佈最佳實踐包括：
- 金絲雀的部署：發佈給一個用戶子集，在這個基礎上進行測試，如果成功，就將其推廣到更廣泛的人群中(如果失敗，就將其撤回到迭代中)。
- 藍綠色部署：從兩個相同的生產環境開始，一個是現場生產，另一個空閒。當推出新版本時，更改將被推到空閒環境中。然後，他們將包含新版本的環境切換為實時環境。如果出現錯誤，、可以立即回滾到另一個環境(不包含新版本的環境)。如果一切順利，環境將再次趨於平等。
- A / B測試:A/B測試在風格上與藍綠色部署類似，但不要與之混淆。A/B測試是一種測試應用程序內部特性的方法，比如可用性。性能更好的勝出。
8、使用按需測試環境應該考慮在容器中運行測試，因為這種方法允許質量保證團隊減少開發和生產環境之間的環境變量和變化。使用這種測試環境的主要優點是它們為CI/CD週期增加了敏捷性。QA團隊不需要從CI服務器提取構建版本，並將其安裝到單獨的測試環境中;相反，它可以針對容器映像運行測試。啟動容器(它們沒有單獨的安裝或配置要求)和在不需要時銷燬它們要容易得多。DevOps或CI/CD最佳實踐的主要目標是自動化構建、測試和發佈軟件的過程。這意味著我們將需要使用DevOps工具，這些工具可幫助簡化自動化並更好地瞭解軟件的進度。此外，應該有一種機制來跟蹤DevOps在整個軟件交付生命週期中的性能指標，並在發佈或部署中出現錯誤時發出警報，以便快速恢復。
