这个程序员如何以一己之力阻止了 Bug 代码的提交并改变整个 DevOps 世界？
【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
譯者：彎月
總結
以上是生活随笔為你收集整理的这个程序员如何以一己之力阻止了 Bug 代码的提交并改变整个 DevOps 世界？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 在 Spring Boot 中使用 Sp
- 下一篇： Cloud Native未来值得关注的方