作者：Sergio De Simone

譯者：蔡芳芳

在整個採訪過程中，GitLab 執行長 Sid Sijbrandij 談到了 GitLab 是如何創立的、GitLab 與競爭對手的不同之處、成為“開放”的公司的重要性、GitLab 工程師如何使用持續整合以及成為一家採用遠端工作方式的公司意味著什麼等諸多話題。GitLab 是 2011 年作為開源雲端 Git 解決方案創立的軟體開發協作平臺。自成立以來，GitLab 一直致力於提供更多的協作工具來支援新的開發實踐，如持續交付和效能監控。GitLab 採用了開放核心的開發模式，平臺的核心部分是開源的，而附加功能僅適用於付費客戶。

關鍵摘要

• 效能監控，同時現代軟體開發也需要更多溝通。
• 對 GitLab 來說，開放原始碼模式不具有可持續性，因此，他們轉而採用開放核心模式，為更大的開發團隊提供更多的功能。
• 成為一家採用遠端工作方式的公司會遇到很多困難，但藉助合適的溝通文化，仍可以成功。
• 持續整合和部署（CI/CD）在 GitLab 開發過程中發揮了重要作用。採用持續整合和部署使程式碼審查更有效並縮短了開發週期，這讓開發人員能更快地發現錯誤並從錯誤中吸取經驗。
• 根據開源開發實踐來進行內部軟體的開發，又稱為內部開源，也是 GitLab 開發過程的基石。

InfoQ：可否說明一下 GitLab 是如何誕生的？在 GitLab 成立的時候，GitHub 已經在雲端 Git 提供商中佔有一席之地，什麼樣的技術或商業原因驅使你進入同一個競技場？

Sid Sijbrandij： Dmitriy Zaporozhets 在 2011 年開始了開源專案 GitLab，因為他不滿足於當時市場上已有的 git 倉庫管理產品。他想要一款他可以負擔得起又支援自託管的產品。當時我是一名自學成才的 Ruby 開發顧問。我接觸到了 GitLab，它的程式碼質量和背後的社群都令我印象深刻。

隨著開源專案的成功——無論從下載量還是活躍的貢獻者數量來看，很顯然，市場對開源自託管的 Git 倉庫管理軟體有很高的需求。雖然 GitHub.com 是一家強大的雲端 Git 提供商，但我們意識到許多企業希望能有一個支援自託管的企業級產品，在提供社交編碼功能的同時，也提供安全和商業保障。為了滿足這些企業開發團隊的需求，Dmitriy 和我決定將重點放在為大型組織提供支援的產品和服務上。

來自企業的市場需求是其中一個驅動因素，另一個則是我們的產品願景，即提供一個整合產品，支援社交編碼、持續整合、應用效能監控等功能。

InfoQ：近年來，提供原始碼託管服務的網路平臺又增加了很多新的競爭者。除了 GitLab 之外，主要還有哪些競爭者，GitLab 的價值主張與對手有什麼不同之處？

Sid Sijbrandij： Git 倉庫管理產品的主要競爭者還有 Atlassian、BitBucket 和 GitHub。事實上，GitLab、GitHub 和 BitBucket 都是基於 Git 的，因此我們都處在同一標準化水平上，尤其當我們只討論程式碼託管的時候更是如此。但是，如果你再想一想那些使用更多現代軟體開發實踐的新一代開發人員，或者正在進行數字化轉換的企業未來的狀態，你就能理解 GitLab 是如何從市場上的眾多工具中脫穎而出的。我們的願景和交付速度將我們與競爭對手區分開來。

從願景方面來看，GitLab 是唯一一款整合產品，它在一個介面上涵蓋了從專案規劃到應用程式效能監控的整個軟體開發生命週期。 我們開發的產品，使企業的開發過程能夠面向未來。現在，他們可能只是開始用 GitLab 進行原始碼管理和持續整合，但隨後當他們想要應用 DevOps 實踐或實現持續交付時，GitLab 已經內建了所需的工具來幫助他們快速啟動這個過程，而無需選用和學習另一款產品。

GitLab 的交付速度和整體開發方式也是一個關鍵的區別。我們在每月 22 日釋出產品的新版本。這意味著我們的客戶不必為了新功能的釋出而等待太久。

最後一個不同之處是我們的開發方式。GitLab 是一個透明度很高的公司。從我們的原始碼到我們的開發路線圖，一切都是開放的。作為一家公司，我們認為協作才能得到更好的結果。因此，我們將幾乎所有的工作都開放給客戶和社群，以找到解決當前和未來挑戰的最佳方案。

InfoQ：GitLab 原本是開源的，這是它與競爭對手的主要區別之一。後來 GitLab 改成了開放核心。你是否能解釋一下，開源對於 GitLab 一開始的成功的重要性以及後來改為開放核心的理由？開源模式有哪些不足？

Sid Sijbrandij： 開源很重要，因為它使我們能夠與我們的社群密切合作。到目前為止，我們的開發路線圖仍是公開的，我們歡迎所有人對功能進行評論並提出自己的建議，甚至可以對他們想要的功能提交合並請求。這也適用於我們的企業版，該產品的原始碼對客戶開放。

開源模式的不足之處在於很難基於它建立商業模式。你需要在安裝、效能、安全性和依賴升級方面做很多工作。如果一切都是開源的，你只能靠提供技術支援來賺錢。我們在 2013 年學到了教訓，由於我們將 GitLab 設計成在安裝和維護方面對使用者十分友好，當一年的訂閱到期之後，客戶很快發現他們在那一年裡根本沒有用到技術支援。因此，靠提供技術支援建立商業模式是不可持續的。反之，我們發現有一些特性和功能對於大型開發團隊（如企業組織）更有用。通過為擁有大型開發團隊或更高階需求的客戶提供額外的功能，我們能繼續通過我們的產品來展示我們的價值。當然，我們仍然提供支援和培訓，因為我們希望通過我們提供的解決方案使團隊能夠專注於核心業務，而不用擔心工具的使用問題。

InfoQ：你一開始進入軟體開發行業的時候是一名 Ruby 程式設計師和開發顧問。GitLab 最初完全用 Ruby 編寫只是巧合嗎？有什麼重要原因讓你們選擇用 Ruby 編寫 GitLab？

Sid Sijbrandij： 在為一家潛艇公司工作了五年之後，我發現了 Ruby，當時對 GitLab 還一無所知。我還記得，當時我認為這就是我一直在尋找的程式設計工具，它將程式設計從繁瑣而乏味的活動變成了能讓人樂在其中的趣事。

我很快自學了 Ruby，並在不久之後轉換職業生涯，成為了一名開發人員。在多家公司擔任顧問幾年後，我遇見了 GitLab，並愛上了它。雖然 GitLab 最初是用 Ruby 編寫的，但一些對效能比較敏感的部分已經用 Go 重寫了。

Ruby 使 GitLab 能夠月復一月不斷地為平臺帶來巨大的改進。大量的測試套件和庫也保證了專案的可維護性。

InfoQ：後來 GitLab 的有些部分已經用 Go 重寫了。是什麼推動了這樣的改變？這種改變帶來了什麼好處？未來 Ruby 和 Go 在 GitLab 專案中分別還會怎麼變化？

Sid Sijbrandij： Ruby 對多執行緒支援得不太好，很容易出錯。而 GitLab 的效能敏感部分（例如訪問 git 儲存庫）又需要用到多執行緒，因此我們將這些部分用 Go 重寫了。我們對這一改變非常滿意，因為它使一切變得更快了。目前我們正在 Gitaly 專案中用 Go 重寫 git 訪問部分的程式碼。

InfoQ：隨著時間的推移，GitLab 已經擁有了非常龐大的開發團隊，處理著許多不同的元件。關於如何使這些團隊或元件高效地溝通，能否分享一下你學到的經驗或教訓？

Sid Sijbrandij： GitLab 僱用了在世界各地遠端工作的員工，我們在 38 個不同國家擁有 170 名員工。我們一直是一家採用遠端工作方式的公司。

僱用遠端工作的員工可能會遇到很多困難，但是我們花了大量的時間來構建並不斷完善我們的員工手冊。現在它成為了一份流動文件，其中詳細介紹了我們的內部流程、團隊資源等。我們的員工手冊是儲存所有重要資訊的“真理之源”。GitLab 的每個員工都可以訪問這個文件，並且他們也可以很方便地查詢文件以瞭解工作中的專案資訊或公司資訊。

儘管員工遍佈全球，但我們營造了促進溝通和聯絡的文化氛圍。我們早期實行的方法之一是每日團隊電話。這個電話持續約 25 分鐘，員工可以利用這段時間分享他們最新的社交編碼成果。在進行通話之前，負責不同功能特性的小組會向整個團隊進行更新部分的展示，並針對他們正在開展的工作進行說明。所有這些更新都會使用 Zoom 記錄，並上傳到我們的 YouTube 頻道。

我們還為員工提供了另一項選擇，他們可以通過申請旅費補助到世界任何一個地方旅行工作。如果 GitLab 員工想與另一個國家的另一位同事合作，他們可以向自己的經理提交旅行計劃，一經批准，該員工將獲得高達 2000 美元的旅費補助。

InfoQ：你最近推出了“跟我學程式設計”這一播客節目，節目聽眾提出的問題中有一個是關於員工激勵的。除了你在那已經分享過的內容之外，你能否再跟我們解釋一下，在 GitLab 平臺每月釋出一次更新的如此漫長的時間裡，你是如何不斷保持 GitLab 團隊成員的動力的？

Sid Sijbrandij： GitLab 非常有幸能擁有一群了不起的人在這裡工作，而這自然對保持員工的動力有所幫助。但我也認為我們有意在整個公司中傳遞我們的願景、價值觀和透明的溝通方式。我們的願景往往代表了整個公司的心聲。我們都對我們的產品充滿熱情，對於我們能向社群和客戶提供的好處也感到非常興奮。我們的價值觀，即關注結果和效率，也有助於提升員工的動力。

GitLab 認為認可也是激勵員工動力的一種工具。例如，我們有一個感謝頻道，你可以隨時點進去檢視和慶祝彼此的成果和努力。最後，我們的溝通風格有助於保持動力。當員工不瞭解公司的發展情況或者不明白自己的角色如何促成公司目標時，就很容易失去動力。我之前提到的功能小組每日更新展示就有助於確保公司中的每個人都知道其他團隊正在做什麼。

InfoQ：定期而頻繁地釋出大量版本的優點和缺點分別是什麼？這些年來 GitLab 管理這個過程的方法有什麼變化？

Sid Sijbrandij： 一開始我們就決定不管公司怎麼發展，我們都想一直做一個致力於為開發人員提供最新最好的工具的組織。為了做到這一點，我們制定計劃在每個月的 22 日釋出更新，以便跟上開發人員使用需求的變化速度。近幾年，我們開始提早給候選釋出版本拉取分支。目前我們會在每個月 7 日完成這項任務。

InfoQ：GitLab 一直堅持頻繁、定期釋出的理念，這個理念與近年來出現的持續整合和部署的關鍵思想有關，你如何看待持續整合和持續部署正在改變軟體行業及實踐這一說法？

Sid Sijbrandij： 持續整合和持續部署已經快速成為開發最佳實踐，它被證明可以幫助團隊更早地捕獲錯誤和更頻繁地釋出更新。隨著持續整合和持續部署成為最佳實踐，越來越多的團隊在開發過程引入持續整合，並且最終也將引入持續部署。採用持續整合和持續部署符合“左移”概念，使更多開發人員能夠將更早也更頻繁的測試作為開發過程的一部分。持續整合和持續交付的做法使開發團隊得以提高開發質量並縮短開發週期。這也是我們開發 GitLab 並將持續整合和持續部署功能與原始碼管理功能整合在一起的原因。

InfoQ：持續整合和持續部署在你們的開發過程中扮演著什麼樣的角色？

Sid Sijbrandij： 採用持續整合和持續部署的組織將更加高效。我們已經體會到了這一點，並認為它對於開發過程至關重要。我們在每次提交程式碼時都會執行持續整合測試。我們不僅使用 GitLab 開發 GitLab，而且還使用它來開發我們的網站，所以 GitLab 持續整合在我們的開發過程中起著十分重要的作用。

我們使用 GitLab 持續整合來改進開發過程，用它來自動執行部分程式碼審查工作。我們的開發人員多於開發組長。由於需要每個月進行一次釋出，我們一直在尋找能夠節省開發組長時間的方法，以便他們能夠高效地工作並審查開發人員提交的所有功能。為了改進這個過程，我們做了一些工作，包括編寫可以捕獲常見錯誤的測試指令碼。如果這些錯誤只出現一次，那它們也許不需要花很多時間修復，但是當我們考慮到在版本釋出日之前所有的開發人員都在合併新功能，哪怕只是一點點自動化都會有所幫助。我們將 GitLab 持續整合功能整合到了我們所有版本的 GitLab 中，以期更多的團隊可以提高程式碼質量，最好還能加快交付速度。

InfoQ：GitLab 是如何把持續整合和持續部署作為關鍵部分融入其價值主張的？是你們在開發 GitLab 時得到的經驗使你們意識到它的重要性，還是有別的因素促使你們這麼做？

Sid Sijbrandij： GitLab 的創始人 Dmitriy 想找一個好的持續整合解決方案來測試 GitLab。最受歡迎的開源產品是 Jenkins，但他不喜歡以前升級 Jenkins 的體驗。就像開發 GitLab 一樣，他想著這能有多難，然後重新開發了一個屬於他自己的持續整合模型。他沒有請求任何人的許可，只是動手去做並做成了。

一年之後，我們有一些使用者提出了有關持續整合的問題，我們分配了兩個人將它做得更具可用性。我們的團隊領導建議將其作為 GitLab 的一部分，但 Dmitriy 最初覺得這與將“小而鋒利的工具”結合在一起的 unix 哲學相違背。

經過對持續整合和持續部署的價值進行多次公司內部辯論之後，我們最終確定要將它整合到 GitLab 中。結果超出了我們的預期。從那時起，我們從未回頭。我們開始整合工具來實現緊急的特性。我們將成功加倍放大，現在也開始把持續部署和測量指標整合到 GitLab 平臺中，包括審查應用程式、金絲雀部署和迴圈分析等功能。

InfoQ：從你的角度來看，成功實施持續整合和持續部署的關鍵點是什麼？

Sid Sijbrandij： 在成功實施持續整合和持續部署之後，開發人員將能夠看到一些幾年前不可能看到的開發活動。例如，利用持續整合和持續部署，開發人員現在可以檢查程式碼的實時預覽，一旦建立了變更立刻就能看到，可以觀察每一個小叢集的部署情況，同時監控每個環境的狀態。

在使用持續整合和持續部署工具之前，開發人員必須等到整個開發生命週期結束才能確定是什麼錯誤導致了程式碼中的缺陷。這個過程往往是耗時、乏味和低效的。它也可能導致開發過程延期，最終影響釋出日期並給開發人員造成金錢損失。

如果你的持續整合和持續部署的工具成功整合，你會發現開發團隊的速度變快了。開發人員全面瞭解開發過程後，就可以在此過程中更早地發現錯誤，並在錯誤造成更大的影響之前從中得到教訓。這點很重要，因為開發人員現在可以更快地學習了。

InfoQ：談到開源實踐，GitLab 長期以來一直是內部開源思想的堅定 支持者，內部開源是 Tim O’Reilly 提出的一個術語，指的是在公司內部使用開源技術。在你看來，最重要的開發實踐是什麼？自 2014 年以來，它們是如何發展的？

Sid Sijbrandij： 自 2014 年以來，我一直堅信，開源組織需要實踐內部開源技術。其中最重要的開發實踐是公司內部的每個專案都應是開放的。GitLab 在公共和私人之間有一個特殊的設定稱為內部。這個設定允許公司內部的所有成員檢視專案，同時又能將伺服器上擁有賬號的外包人員排除在外。

這樣做可以讓不同的團隊成員重新組合和重用程式碼，使組織變得更高效。這也能提高安全性，因為開發人員可以更容易地發現和識別程式碼中的安全漏洞。在過去三年中，越來越多的企業使用開原始碼。今天，越來越多的開發人員熟悉分支工作流程，在這種工作流程中你無需原始碼庫的寫入許可權就可以提出建議。

關於採訪物件  

GitLab 執行長 Sid Sijbrandij 最初是私人潛艇公司的程式設計師，後來自學 Ruby 程式設計併成為 Ruby 程式開發人員，經介紹進入 GitLab。自 Sid 擔任公司高層後，GitLab 發展迅速，在由 August Capital 發起的 B 輪投資中獲得了 2000 萬美元的投資，並承諾為 IBM、Macy’s 和 Verizon 等客戶的完整開發生命週期提供解決方案。

文章來自微信公眾號：高效開發運維