來源：https://about.gitlab.com/blog
作者：Itzik Gan-Baruch

在如今軟件研發的動態格局中，某些要求對於快速交付高質量的軟件變得至關重要。這些需求包括對雲兼容性的需要、更快的研發迭代週期、高效的協作、容器化、良好的研發體驗以及為了更高的效率及速度而集成的一些 AI 能力。

Jenkins，一款歷史悠久且備受推崇的持續集成工具（CI），這麼些年來在很多團隊的軟件研發過程中扮演了很重要的角色。然而，隨着越來越多的團隊採用 DevOps/DevSecOps 策略來推進現代化應用程序的交付，利用一款在 DevSecOps 平台（比如極狐GitLab）中開箱即用的持續集成工具能夠讓應用程序的開發受益良多，而這些都是 Jenkins 所無法提供的。

有些組織在面對遷移時顯得有些猶豫，這並不是説他們在懷疑極狐GitLab CI/CD 所能帶來的價值，而是因為他們既有的 Jenkins 架構及使用的複雜性。這種轉變看起來有點讓人恐懼，但是也是能夠理解的。

在本文中，你會發現多種能夠從 Jenkins 平滑遷移到極狐GitLab CI 的方法，而且不會對當前業務造成中斷。本文的大綱大概為：

• 遷移到極狐GitLab；
• Jenkins 到極狐GitLab CI 的遷移指南；
• Jenkins 到極狐GitLab CI 的三種遷移策略；
• 技術洞察：遷移是如何工作的；
• 平滑遷移的策略；
• 極狐GitLab 文檔和支持。

遷移到極狐GitLab

很明顯的是，對於那些尋求企業級 CI/CD 解決方案以應對其不斷變化的需求的組織來説，極狐GitLab 已經成為了一個強大的遊戲規則改變者。讓我們來一起探討一下為什麼遷移到極狐GitLab CI 平台對於 Jenkins 用户來講是一場變革。

為什麼需要遷移到極狐GitLab

在我們深入遷移篇章之前，先花點時間來了解一下極狐GitLab CI，並且明白為什麼它成為了滿足現代 CI/CD 需求的企業級解決方案。

極狐GitLab CI 概覽

極狐GitLab CI 是企業級一體化 DevSecOps 平台的一部分，提供了一個完善且統一的 DevSecOps 和企業級 CI/CD 解決方案。極狐GitLab 的設計圍繞簡化研發工作流、促進協作、增強安全性以及確保擴展性而展開。

極狐GitLab CI 的功能特性

以下是極狐GitLab CI 的一些重要功能特性：

• 統一的平台： 極狐GitLab CI 不僅僅是一個 CI 工具；它是一個碩大生態的一部分，這個生態還包括源代碼託管、項目管理、安全管理以及效能分析等。這個統一的平台能夠簡化工作流而且讓研發團隊的協作變得高效；
• 容器化及容器編排：極狐GitLab 的 CI/CD 設計充分考慮了容器化，天然支持 Docker 和 Kubernetes。這能夠在 CI/CD 流水線中無縫集成容器技術；
• 默認安全的設計：安全是最高優先級，而極狐GitLab CI 的企業級功能特性，諸如靜態代碼分析以及漏洞掃描能夠在研發流程的早期幫助團隊識別和解決安全問題；
• GitOps 理念：極狐GitLab CI 和 GitOps 的理念是一樣的，那就是強調版本控制以及對基礎設施和應用程序部署的聲明式配置。這種方法能夠加強應用部署的可靠性和可重複性。

瞭解了極狐GitLab CI 的能力後，接下來我們探討那些希望利用極狐GitLab CI 優勢的 Jenkins 用户所需要的遷移步驟和策略。

Jenkins 到極狐GitLab CI 的遷移指南

當考慮從 Jenkins 遷移到極狐GitLab CI 時，我們強烈推薦下面這個步驟清晰的手把手指南，以確保遷移的平滑過渡。遷移步驟如下：

• 流水線評估：首先要對 Jenkins 中的所有現有流水線進行全面的盤點。這一初始操作將幫助你瞭解遷移的整個範圍以及所面臨的複雜性；
• 並行遷移：接下來就是開始遷移工作，選擇一些單個的流水線，然後將它們一次性全部遷移到極狐GitLab CI 上。為了將業務中斷的風險降低到最小，在這個過渡期間，還需要對 Jenkins 進行持續的維護；
• 代碼驗證：我們建議從 CI 中的驗證檢查開始。並行運行 Jenkins 和極狐GitLab CI 流水線。這種雙重方法允許你對兩種工作流進行對比，並且快速識別新的極狐GitLab 工作流中出現的問題。在這個階段，將極狐GitLab 工作流作為一個可選項，而 Jenkins 依舊是運行主力；
• 持續驗證：兩種流水線並行運行一段時間後，要對每一種流水線的結果進行一個完整的評估。評估的過程需要考慮多種因素，包括狀態碼、日誌以及性能；
• 極狐GitLab CI 過渡：當在並行運行過程中對極狐GitLab CI 的可靠性和有效性充滿信心時，進行一下過渡，也就是讓極狐GitLab 工作流成為主流，而 Jenkins 在背後持續運行；
• Jenkins 的逐步退出：經過一段時間的迭代後，當你對極狐GitLab CI 的穩定性和性能充滿信心時，你就可以在代碼驗證流水線中刪除 Jenkins 作業了。這一成功的轉變將使你能夠從 CI/CD 流程中的某些特定方面徹底退出 Jenkins。

上面的的方法能夠確保遷移的過程是循序漸進的，而且能夠允許在全面轉向極狐GitLab CI 之前識別和解決發現的問題以及一些差異性。而並行運行極狐GitLab CI 和 Jenkins 流水線能夠提供有價值的洞察，並確保有效簡化 CI/CD 的流程。

遷移準備：培訓和溝通

為了確保從 Jenkins 遷移到極狐GitLab CI 的平滑和成功，需要遵循以下一些必要的步驟：

• 和利益相干人溝通：要向所有的利益相干人宣佈你的遷移計劃和時間線。這些人包括 DevOps 團隊、研發人員以及 QA 工程師。溝通透明性是非常重要的，因為這能夠確保每個人都能夠了解目標以及遷移的期望；
• 相關知識培訓：為團隊舉辦相關知識的培訓課程，來促進大家對極狐GitLab CI 的採用。可以包含的主題有極狐GitLab CI 的使用、YAML 語法的理解以及基本流水線的創建等。讓團隊成員具備足夠的知識和技能對於遷移到全新且高效的極狐GitLab CI 環境來説是非常有必要的；
• 實踐學習：通過與開發人員結對來鼓勵動手實踐。在整個遷移過程中，為他們創造機會來學習彼此的經驗。

通過遵循上述的培訓和交流指南，你將會為成功的遷移奠定一個堅實的基礎，而且能夠幫助你的團隊適應新的環境並快速發展。

Jenkins 到極狐GitLab CI 的三種遷移策略

有三種遷移策略可供考慮。這三種策略提供了靈活性，允許組織根據自身特定需求和資源來選擇最佳的遷移路線。接下來我們將通過探索這些遷移策略的詳情來幫助你做一個最適合組織的聰明決定。

遷移策略 1：為新項目使用極狐GitLab CI

第一種遷移策略是漸進性的。對於既有項目需要繼續維護其 Jenkins 的基礎設施，但是對於新項目可以引入極狐GitLab CI。這種方法既能夠讓你充分利用極狐GitLab CI 的眾多功能，同時又不會讓你的當前業務發生中斷。

➤ 遷移策略 1 的優勢

• 對於新項目來説，能從開始階段就充分利用極狐GitLab CI 的高級功能特性；
• 這種策略能夠將既有工作流的中斷風險降到最低，因為 Jenkins 的工作流依舊在持續工作；
• 團隊可以漸進式的採用極狐GitLab CI，從而增強信心、豐富經驗，同時又不會有大規模遷移時的壓力。

➤ 遷移策略 1 的挑戰

• 同時維護兩套 CI/CD 系統帶來了更多複雜性，特別是對工具集成和團隊協作來講；
• 在不同平台上管理項目可能需要仔細協調，以確保流程和安全實踐的一致性。

這種策略提供了一種平滑且可控的遷移，因為這能夠讓你在新項目中體驗極狐GitLab CI 的功能，同時 Jenkins 還能為既有項目提供支持。

遷移策略 2：只遷移戰略性項目

在這種策略中，先識別出組織內那些能夠從極狐GitLab CI 能力中獲益最多的項目。你不需要準備做大規模遷移，而是首先集中精力遷移這些戰略性選擇的項目。

➤ 遷移策略 2 的優勢

• 通過聚焦在關鍵項目上，你可以在極狐GitLab CI 滿足特定需求的領域內實現重大改進；
• 這種方法減少了同時遷移所有項目所帶來的複雜性，將業務的中斷風險降到最小；
• 在考慮進一步的遷移之前，能夠使用極狐GitLab CI 的功能和優勢來逐漸構建足夠的信心。

➤ 遷移策略 2 的挑戰

• 儘管你不是遷移所有的項目，但是對選定項目進行遷移依舊是錯綜複雜的，而且需要仔細完備的計劃；
• 需要確保不同平台上項目之間的無縫協作。

這種遷移策略通過聚焦戰略項目遷移，將極狐GitLab CI 的影響最大化，同時將業務中斷風險最小化，而且逐漸豐富使用新工具的經驗。

遷移策略 3：全面遷移

第三種策略是進行完整的遷移，將 CI/CD 流程、項目以及工作流全面遷移到極狐GitLab CI。這種方法旨在實現所有項目中 CI/CD 的統一和簡化。採用迭代遷移的方法能夠讓該策略的收益最大化。首先從新項目開始，戰略性項目緊隨其後，最後利用前期積累的極狐GitLab CI 經驗來完成剩餘項目的整體遷移。

➤ 遷移策略 3 的優勢

• 所有項目使用統一的 CI/CD 流程，從而簡化了流程的管理和維護，同時降低了複雜性；
• 可以充分利用極狐GitLab CI 的所有能力，從基礎設施即代碼到全面的安全特性等；
• 隨着項目的增加，極狐GitLab 能夠處理不斷增長的需求，確保了 CI/CD 流程的可擴展性。

➤ 遷移策略 3 的挑戰

• 大規模遷移是錯綜複雜的，需要周密的計劃和實施；
• 遷移可能會擾亂當前的某些項目，而且需要大量的時間投入；
• 培訓方面的投入和潛在的遷移工具所帶來的額外費用都要考慮進去。

如果 CI/CD 流程的統一和資源整合是第一要務時，你可以考慮這種遷移方法，而且你還需要確保有足夠的資源來完成整個遷移。

遷移策略的選擇需要與企業自身需求與實際情況相契合。但是，所有策略的最終目標是一致的：那就是使用諸如極狐GitLab CI 這樣的現代化 CI/CD 工具來簡化軟件研發流程，提高軟件研發效率，因為極狐GitLab CI 能夠提供完美契合現代軟件研發需求的眾多功能特性，諸如足夠的擴展性、基礎設施的自動化、安全性以及協作溝通等。

技術洞察：遷移是如何進行的？

將 CI/CD 工作流從 Jenkins 遷移到極狐GitLab 是極具變革性的一場旅途，如果瞭解遷移背後的運行原理的話，對於完成遷移來説是非常關鍵的。

瞭解配置文件的不同：Jenkinsfile vs .gitlab-ci.yml

CI/CD 流水線的核心在於定義在配置文件中的內容，對於 Jenkins 來講這個配置文件就是 Jenkinsfile，而對於極狐GitLab 來講，這個配置文件是 .gitlab-ci.yml。這兩種配置文件有一些相似的地方，同樣也有很多不同的地方。

➤ 相似性

• 兩種文件都定義了 CI/CD 流程中所用到的 stages、jobs 以及 steps；
• 兩種文件中都會指定諸如構建（build）、測試（test）以及部署（deployment）之類的步驟；
• 兩種文件中都可以進行環境變量的設置。

➤ 不同點

• Jenkinsfile 使用 Groovy 語言編寫，而 .gitlab-ci.yml 使用 YAML 文件。這種語言的差別會影響你對整個 CI/CD 流水線的編寫和構造；
• 使用更清晰、更易讀的語法在 .gitlab-ci.yml 文件中定義流水線會更加直觀；
• 極狐GitLab CI 提供了一系列內置的模板和預定義作業，大大簡化了配置並且減少了定製化腳本的需求。

手動轉換流水線配置

當前，將既有的 Jenkins 流水線遷移到極狐GitLab CI 通常都是手動完成的。這意味着需要分析你的 Jenkinsfile 然後在 .gitlab-ci.yml 文件中重新創建同等功能的配置。儘管在概念和構造方面有很多相似性，但是語法和每個平台的能力都有所不同，因此在遷移期間這些都需要額外的考量。

平滑遷移的策略規劃

從 Jenkins 遷移到極狐GitLab CI 需要細緻的計劃來確保無縫過渡。評估兩個系統之間的差異及對當前工作流造成的影響是非常重要的，考慮的因素有很多，比如安全、成本時間以及容量等。

一旦你確定了這些差異並確定了遷移策略，就可以將遷移策略分解為一些關鍵步驟了。這些步驟包括極狐GitLab CI 流水線的設置、數據從 Jenkins 到極狐GitLab CI 的安全遷移以及將極狐GitLab CI 集成到你現在的工具和流程中。

極狐GitLab 文檔和支持

對於那些想要進行遷移的用户來講，極狐GitLab 提供了詳細的文檔來對整個流程進行指導。可以在極狐GitLab 官方文檔中找到你想要的內容。

除了官方文檔以外，極狐GitLab 的專業服務團隊能夠幫助企業級客户進行遷移。他們的經驗和能力能夠讓遷移平滑進行。無論是瞭解 Jenkinsfile 到 .gitlab-ci.yml 轉換的細微差別還是優化 CI/CD 工作流，他們的支持都是專業且極具價值的。