【CSDN 編者按】Jenkins 是基於 Java 開發的一種持續整合工具，能夠幫助專案實現高度的工程化，而它的前身則是 Hudson。2004年，Sun 公司的 Java 程式設計師川口耕介為了讓同事的工作更輕鬆些，創立了持續整合工具 Hudson，但這之後，這個工具打敗了許多歷史悠久的框架，並在 2007 年開始逐漸取代 CruiseControl 和其他開源構建工具的江湖地位。

但在 2010 年 Oracle 對 Sun 收購帶來了 Hudson 所有權問題後，社群採納了將專案名稱從“Hudson”改為“Jenkins”的投票結果，於 2011 年建立了 Jenkins 專案——99% 的 Hudson 開發人員都轉向了 Jenkins 開發，包括最初的建立者川口清子。現在，Jenkins 已經支援超過 1000 個外掛，並憑藉多樣而強大的外掛成了整個開發生命週期中的一箇中心點。

本文中則採訪了 Jenkins 之父（現任 CloudBees CTO）川口清子，解答了關於 Jenkins 的來歷和未來計劃等問題。

以下為譯文：

在對著一大群 DevOps 愛好者發表了一番激動人心的演說之後，Jenkins 專案創立者（現任 CloudBees CTO）的川口清子花了些時間，給我們解答了 Jenkins 的來歷、未來計劃、以及他是不是真的有時間參與其中等問題。

創立持續整合工具 Hudson

最後一點的答案是：沒有太多時間。但這也並不一定是壞事，因為川口告訴我們，他曾經有個習慣，就是留下很多 bug。2004 年他在 Sun 微系統公司做 Java 程式設計師時，他經常收到同事打來的電話。

“他們會突然發現整個專案無法編譯了，或者出了別的錯誤。他們給我打電話說：‘我看到上次修改是你做的。你能看看是怎麼回事嗎？’通常原因都是我犯的錯誤。”

就像任何優秀的程式設計師一樣，川口決定用程式碼來解決這個問題。“我覺得這種事情出過太多次了，所以我決定寫個程式。”

這個程式就是後來的 Hudson，一個持續整合工具，之後這個工具打敗了許多歷史悠久的框架，比如基於 Java 的 CruiseControl 等。

但是，川口並沒有考慮過競爭的問題，他只想讓同事的工作更輕鬆些。有了 Hudson，程式設計師就可以從自己的任務列表上去掉構建和整合這兩項工作。“我們能夠轉交給自動化和計算機的任務越多越好。”

但是，川口已經注意到 Sun 開始走下坡路了。“許多優秀的人都離開了。”他說，但由於有了 Hudson，新入職的人培訓速度加快了。他說，“我發現，這也是 Hudson 降低人們思想負擔的一種途徑，能讓新人專注學習他們應該學習的東西，從而更快地提高生產力。”

走向開源

受到當時 Sun 開源部分原始碼的啟發，也因為這個專案已經變得過於龐大，無法再用個人時間維護，於是川口決定將專案開源。

“嗯，對於我來說這個過程非常自然。實際上我甚至覺得要是不開源就根本不可能實現現在的程式……而且，當時在 Sun 微系統公司，我們也在嘗試在開源的基礎上開展一切工作。”

川口對於專案開源的結果非常滿意：“感覺就像建個所有人都能享受的大帳篷。人們在交換想法的同時改進想法，而交換想法的最好方式就是讓更多的程式碼開源。”

出任 CTO

Sun 的逝去眾人皆知。公司於 2010 年被 Oracle 收購，Hudson 這個名字也被收為註冊商標。但是，程式碼早已經分叉，專案於 2011 年以 Jenkins 的名義繼續進行。而 Hudson 歸屬於 Oracle，後來交給了 Eclipse 基金會，並最終於 2017 年被棄用。

由於對 Oracle 感到失望，川口在 2011 年以 InfraDNA 的形式開始對 Hudson 提供支援。同年晚些時候，CloudBees 招募了川口，並任命他為 Jenkins 專家的 CTO。

對於川口來說，成為 CTO 的體驗很不錯。“CTO 是最奇怪的角色。這個角色定義得並不好……我發現過去將近十年內，我的角色經常發生變化……我必須找出自己的定位。我曾經因此感到十分焦慮，但我現在很喜愛自己的角色。”

關於 Jenkins 和 CloudBees 的未來

作為 CTO，川口承認他被各種選擇“慣壞了”。雖然他這些日子在 Jenkins 專案上花的時間少了，但他表示“我能選擇的每件事情都很有趣。與客戶交涉很有趣，寫程式碼也很有趣，孵化新專案更加有趣。”

關於未來，川口對於 2019 年即將出現的合規和治理模型感到十分興奮，這個模型可以讓管理員在不滿足特定條件的情況下停止某個管線。這個模型對於需要合規的企業非常有吸引力。

談到這些，他說：“合規和治理實際上非常符合我的心意。我認為，大型企業無法快速前進的主要原因就在於此。”

“所以，我認為我們可以幫助他們在軟體開發方面做得更好，就像我們給世界帶來了重大影響一樣。”

川口關心的另一個領域是測試。測試是 CI/CD 過程中重要的一個步驟（至少它鼓勵了人們去寫更多的測試）。但是他擔心，雖然有“更多的測試能讓軟體開發變得更乾淨……但並沒有太多規則來評價這些測試的質量如何。”

“通常，在進入產品前變更的驗證絕大部分時間都被測試佔據了。”

測試用例的自動化生成依然是個難題。川口知道利用機器學習能找出錯誤，但這種過程目前依賴於自動化。相比之下，他更感興趣的是根據過去的成功和失敗的執行產生的大量資料來安排測試的執行順序。

此外，當然也需考慮終端使用者。川口注意到，他訪問過的一些公司採取了這樣的流程：將一小部分產品流量作為最後一個測試階段，但必須強調，這種流程必須非常謹慎，“以免影響到客戶”。

最後一點祕籍

川口的作品對於開發社群的影響是不可否認的。雖然 Jenkins 之父的參與減少了，但他依然認為“即使在十年以後，Jenkins 社群依然存在自我進化的能力。”

社群帶來的持續不斷的開發和重新發明讓他對該框架充滿了信心。“我覺得這正是整個 Jenkins 專案的祕籍。它能夠不斷重新定義自己。”

英文：How one programmer's efforts to stop checking in buggy code changed the DevOps world

連結：https://www.theregister.co.uk/2018/11/09/jenkins_interview/

作者：Richard Speed

譯者：彎月