Jenkins已經老了 - ITNEXT

構建配置
Jenkins核心是Jobs，這些構建配置告訴Jenkins什麼以及如何做事。

Web UI
起初一切都是透過UI完成的。所有專案都是透過非常易於使用的Web表單進行配置的。起初這很棒。但很快就發現這很難備份和維護。隨著對程式碼配置的不斷增長的需求，這並不適合。配置大量作業非常繁瑣且容易出錯。維護這些配置更加困難。

工作DSL
接下來是Jenkins Job DSL。這是面向配置驅動開發的可喜步驟。Jenkins Job DSL允許您使用Groovy 編寫工作程式碼。您可以建立可重用的類和方法來生成10,100,1000的作業，而作為管理員的工作很少。作為額外的好處，我們還可以控制作業配置。

def gitUrl = 'git://github.com/jenkinsci/job-dsl-plugin.git'
job('PROJ-unit-tests') {
    scm {
        git(gitUrl)
    }
    triggers {
        scm('*/15 * * * *')
    }
    steps {
        maven('-e clean test')
        maven('-B release:prepare release:perform')
        shell('cleanup.sh')
    }
}

Jenkins管道
最近，Jenkins Pipeline或許多人將它們稱為Jenkinsfile，因為構建是從Jenkinsfile名稱的儲存庫中的特殊檔案驅動的。Jenkinsfile將控制權交還給開發人員。構建配置與程式碼一起儲存。這允許不同分支的行為不同，具體取決於該分支中的Jenkinsfile配置。SA仍然可以維護一組核心功能，開發人員可以將這些功能匯入到指令碼中並根據需要進行自定義。

pipeline {
    agent any 
    stages {
        stage('Build') { 
            steps {
                // 
            }
        }
        stage('Test') { 
            steps {
                // 
            }
        }
        stage('Deploy') { 
            steps {
                // 
            }
        }
    }
}

外掛
外掛很棒。它們允許第三方將新功能寫入Jenkins。我們將包含各種內容的頁面合併在一起。例如，我可以擁有一個顯示程式碼覆蓋率，單元測試歷史記錄，靜態程式碼分析趨勢等的構建。很棒的權利。從表面上看是的。
但外掛有一個黑暗的一面。
由於外掛和外掛版本，維護Jenkins是一場噩夢。外掛是在INTO Jenkins中部署的，作為單個Jenkins Master Web容器的一部分，這意味著它們共享一個共同的類路徑。
我怎麼知道我是否會破壞了某些東西？
很多時候升級Jenkins也會更改底層配置檔案。如果您使用Jenkins Job DSL，那麼您必須確保它與您的Jenkins版本和所有已安裝的外掛保持同步，這會強制您擁有多個Jenkins例項。但是你不能輕易地用Jenkins做傳統的金絲雀部署模式。
這最終導致新功能停滯不前並延遲升級。

檔案資料
Jenkins生成並用於渲染所有可愛構建結果頁面的所有資料都儲存為檔案。很多，很多很多檔案。這使得Jenkins的表現非常出色。
大型管道檢視花費幾秒鐘渲染並不罕見。這些大檔案也使Jenkins記憶體密集。很多時候Jenkins將這些檔案解析為整個DOM，將檔案的全部內容載入到記憶體中。Jenkins使用幾千兆位元組的堆大小並不罕見。實際上，我們的生產Jenkins例項只有一個32 GB的堆來保持執行

記憶體
說到記憶體，因為所有外掛實際上都是載入到Jenkins中的程式碼，所以看到大量記憶體洩漏是很常見的。這不是Jenkins的核心故障，但它仍然會取消伺服器。我們現在安排定期重啟Jenkins例項以減輕記憶體洩漏。

系統Groovy指令碼
如果您每個人都想使用System Groovy指令碼，請不要這樣做！你會（將）把Jenkins搞得一團糟。這是因為指令碼不是分叉程式，而是指令碼執行在Jenkins內部。這是有目的的，因為作為系統groovy指令碼，您希望訪問Jenkins本身和實際執行的類。但這意味著您還可以訪問執行Jenkins的直接JVM和程式。因此，你可以搞亂類路徑，堆，甚至把整個事情搞砸（System.exit？）

Jenkins配置
雖然Job DSL和Jenkins檔案有助於配置Jobs，但在配置Jenkins本身時卻做得很少。您需要將Jenkins配置為連線到靜態從屬或Mesos群集，或者設定安全性或配置環境變數，構建工具等。作業DSL有一些可用於執行此操作的庫，但它們很難理解且無法測試。

無法測試​​​​​​​
我曾經說過一次，兩次，數千次。Jenkins是不可能測試的。誰會使用無法測試的程式語言？除了在生產中，沒有人！有些人可能會說你當然可以測試Jenkins。相信我，我試過了。你是如何真正測試它的？我們已經嘗試啟動Jenkins的本地例項，但是在實際執行構建時會很快崩潰。實際配置怎麼樣？您需要配置對群集的訪問許可權，模擬關鍵基礎架構，如artifactory和DTR。這真的很難。最重要的是，您希望測試不會影響實際系統。有幾次我們的“測試”由於缺乏隔離而導致生產問題。

升級​​​​​​​
我在外掛中簡要提到了這一點，但升級是一個真正的問題。當你升級一個外掛甚至Jenkins本身的全部或全部。如果您有一個需要較舊版本外掛的作業，而另一個需要較新版本的作業則會被卡住。您將需要多個Jenkins例項。遷移到新版本並不總是可行，因為升級外掛也會導致底層XML也發生變化。因此，回滾幾乎是不可能的。

Jenkins Web UI
實際的Web UI在一個名為Jenkins Master的Web容器上執行。你只能擁有其中一個。它不支援任何型別的群集或故障轉移。因此，如果你有一個非常龐大的開發團隊，所有人都打到Jenkins，那麼一個例項需要非常強大並且不斷受到監控。

結論
詹金斯的核心問題是它是一個單體巨石，一切耦合在一起。
我理想的CI / CD系統需要：

• 支援某種單元測試工作
• 完全斷開連線
• 水平可伸縮
• 模組化
• 擴充套件