持續集成（CI）
持續集成注重將各個開發者的作業集合到一個代碼倉庫中，通常每天會進行幾次， 主要目的是盡早發現集成錯誤，使團隊更加緊密結合，更好地協作， 持續交付的目的是最小化部署或發布程序中團隊固有的摩擦， 它的實作通常能夠將構建部署的每個步驟自動化，以便任何時刻能夠安全地完成代碼發布（理想情況下）， 持續部署是一種更高程度的自動化，無論何時代碼有較大改動， 都會自動進行構建／部署，通過持續集成，開發人員能夠頻繁地將其代碼集成到公共代碼倉庫的主分支中， 開發人員能夠在任何時候多次向倉庫提交作品，而不是獨立地開發每個功能模塊并在開發周期結束時一一提交，
這里的一個重要思想就是讓開發人員更快更、頻繁地做到這一點，從而降低集成的開銷， 實際情況中，開發人員在集成時經常會發現新代碼和已有代碼存在沖突， 如果集成較早并更加頻繁，那么沖突將更容易解決且執行成本更低，
當然，這里也有一些權衡，這個流程不提供額外的質量保障， 事實上，許多組織發現這樣的集成方式開銷更大，因為它們依賴人工確保新代碼不會引起新的 bug 或者破壞現有代碼， 為了減少集成期間的摩擦，持續集成依賴于測驗套件和自動化測驗， 然而，要認識到自動化測驗和持續測驗是完全不同的這一點很重要，
持續交付（CD）實際上是 CI 的擴展，其中軟體交付流程進一步自動化，以便隨時輕松地部署到生成環境中， 成熟的持續交付方案也展示了一個始終可部署的代碼庫，使用 CD 后，軟體發布將成為一個沒有任何緊張感的例行事件， 開發團隊可以在日常開發的任何時間進行產品級的發布，而不需要詳細的發布方案或者特殊的后期測驗，持續部署（CD）
持續部署擴展了持續交付，以便軟體構建在通過所有測驗時自動部署，在這樣的流程中， 不需要人為決定何時及如何投入生產環境，CI/CD 系統的最后一步將在構建后的組件/包退出流水線時自動部署， 此類自動部署可以配置為快速向客戶分發組件、功能模塊或修復補丁，并準確說明當前提供的內容，
采用持續部署的組織可以將新功能快速傳遞給用戶，得到用戶對于新版本的快速反饋，并且可以迅速處理任何明顯的缺陷， 用戶對無用或者誤解需求的功能的快速反饋有助于團隊規劃投入，避免將精力集中于不容易產生回報的地方，
隨著 DevOps 的發展，新的用來實作 CI/CD 流水線的自動化工具也在不斷涌現，這些工具通常能與各種開發工具配合， 包括像 GitHub 這樣的代碼倉庫和 Jira 這樣的 bug 跟蹤工具，此外，隨著 SaaS 這種交付方式變得更受歡迎， 許多工具都可以在現代開發人員運行應用程式的云環境中運行，例如 GCP 和 AWS，
最受歡迎的自動化工具是 Jenkins（以前的 Hudson）， 這是一個由數百名貢獻者和商業公司 Cloudbees 支持的開源專案， Cloudbees 甚至聘請了 Jenkins 的創始人，并提供了一些 Jenkins 培訓專案和附加組件， 除了開源專案之外，還有一些更現代化的商業產品例如 CircleCI，Codeship 和 Shippable， 這些產品各有優缺點，我鼓勵開發人員在開發流程中一一嘗試它們，以了解它們在您的環境中的作業方式， 以及它們如何與您的工具、云平臺、容器系統等協作，
里面需要的細節技術點
我已經整理了Docker的教程，以及學習路線 docker資料卷掛載 -> Dockerfile -> docker-網路 -> docker-compose -> docker-swarm -> Docker Stack -> Docker Secret -> Docker Config 一直到 K8s的一個方向，
關注博主不迷路，博主帶你上高速，(別誤會，我不開車) 后期有時間給大家整理Jenkins哦~
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/110709.html
標籤：Java