不是吹牛，但我所管理的開發團隊在軟件開發速度上表現出色，能夠高質量地編寫代碼，並在白噪聲的陪伴下保持高效。

但就像所有的故事一樣，一開始並不是這樣的，甚至相去甚遠。我們經歷了時間、溝通、合作、失敗、成功以及許多關於生產力的會議（有時很尷尬，但它們幫助我們找出了困擾我們的問題......另外，我同事會製作他的拿手餅乾，所以是雙贏的）。接下來，我將直接跳入主題，與你分享我團隊的成功經驗。

首先，我會提供一些事實來為場景做鋪墊：一名普通的開發人員在一天內平均可以編寫大約100行代碼。這已經是相對高效的開發人員的產出了。有些開發人員每天可能只產出五行或十行代碼。考慮到一個手機應用程序大約包含5萬行代碼，所以這並不是一個特別高的數字。如果程序員每週只能生產出幾百行代碼，那麼編寫一個應用程序會需要很多很多開發工作日。

這就是為什麼開發團隊需要不斷地尋找加速代碼生產的方法。他們需要克服減緩軟件開發的瓶頸，然後找到一些工具和流程，解決他們在持續編寫和部署應用程序時面臨的挑戰（這就是我們在吃餅乾的會議中討論的內容）。

現在，我們都知道，要實現這一目標，持續集成（CI）流水線是一個很好的起點。儘管導致代碼生產時間超過預期的原因有很多，但初始化、配置和執行CI流水線時出現的問題卻是最常見的。開發人員在設置和管理CI流水線或解決構建失敗的問題上花費的時間越多，他們完成主要工作（編寫創新代碼）的時間就越少。此外，能夠花更多時間編寫代碼，而不是與CI工具糾纏不清的開發人員往往更加幸福。

這是最重要的一點，因為這是讓開發人員快樂的原因。他們希望編寫有意義的代碼，為最終結果做出貢獻，無論代碼是否支持更好的用户體驗（誰沒有經歷過一個不能提供所需功能的應用程序的憤怒），或是增加安全性（以便任何人都可以放心使用您的軟件，包括您的祖父母），或者因為寫得精巧收穫了一眾粉絲的崇拜。

大多數程序員選擇他們的職業是因為他們喜歡寫代碼，而不是因為他們喜歡手動設置軟件，也不是因為他們喜歡在CI日誌中查找為什麼構建時間超出預期。

好了，背景故事説夠了，我將開始分享我在解決軟件交付生命週期中的那一部分“機器”的經驗——流水線。

我們都知道，一個結構良好的CI流水線可以確保開發人員快速高效地編寫、集成和構建新的應用程序代碼。然而，設置一個高效的CI流水線可能會是一項繁重的工作。特別是在需要啓動多個流水線的情況下，每個流水線都需要稍微不同的配置。如果開發人員必須從頭開始設置每個CI流水線並手動調整它，他們可能會在編寫第一行代碼之前，就花費數週的時間來初始化流水線。如何在這裏運用“避免重複原則（Do not repeat yourself，也被稱為DRY軟件開發原則）”呢？反覆做同樣的事會令人沮喪，尤其是越做離目標反而越遠的時候。

確保流水線配置符合組織標準或法規要求只會讓問題變得更加複雜。對於開發人員來説，瞭解他們的流水線需要滿足哪些標準都有點難，更別説以有效的方式實施這些標準了。

所以，在這裏，我列出了採用的部分功能，來幫助我們解決流水線挑戰。此篇文章是第一篇，會帶來其中兩個挑戰的解決方案。在系列文章的最後，我還會添加我們選擇的解決方案。

我們所面臨的挑戰是相當普遍的，我們選的解決方案解決了這些問題，並且提供了可衡量的成功，讓每個人都很開心，包括首席執行官，他居然笑了。希望你也能在其中找到自己面臨的挑戰，並找出適合的解決方案。

挑戰1：緩慢的流水線初始化（也就是我們避免DRY的過程）

流水線模板和流水線模板目錄在這裏起到了關鍵作用，避免了在創建流水線時重複操作。這些功能讓CI管理員和開發團隊以模板的形式定義標準流水線配置。在創建了這樣的模板之後，管理員或開發人員可以通過配置流水線模板目錄將其共享給整個企業。該目錄會根據團隊的不同，將流水線模板組織成不同的組。後端有一組與前端不同的模板可供選擇。所有這些模板都在一個地方進行維護，並且可以讓團隊自動地抓取和部署。

通過使用流水線模板和模板目錄，開發人員在初始化流水線時節省了大量時間和精力，而且在確定如何配置流水線以滿足特定於域的要求時，猜測也大大減少。

挑戰2：自定義CI配置（又名靈活性，為了滿足特殊需求）

雖然在多個項目和開發團隊中，模板是簡化流水線初始化的有效方法，但一個流水線適合某個團隊，也不一定適合別的團隊。這意味着配置需要靈活，滿足現在和以後的需求。

例如，我曾經有一個團隊喜歡某個集成工具，但它沒有內置到我們的CI配置中。我們需要一種方法，既能讓他們自定義配置，又能符合我們經過測試和批准的CI配置。該怎麼辦呢？我當然不會阻擋開發人員想要這個工具來提高生產力的願望。

為了解決這個問題，我們首先讓每個開發人員對CI流水線擁有完全的管理員權限。這解決了允許開發人員自定義配置的挑戰。隨後我們發現這種方法存在問題，因為這導致了混亂和不符合規範。如果單個開發人員可以在沒有監督或控制的情況下，部署他們想要的任何插件或配置更改，那麼團隊最終可能會得到違反企業或監管標準的流水線，甚至可能導致不穩定性。我們需要一起解決這個問題。

對我們來説，更好的解決方案是利用配置即代碼（Configuration as Code，簡稱CasC），它提供了一個可管理的基於Git的工作流，讓開發人員可以請求CI配置更改，並在應用更改之前使用自動化測試進行驗證。具體流程如下：

當開發人員想要更改託管控制器（例如Jenkins®實例）的配置時，開發人員會在Git上發出拉取請求；

拉取請求觸發新的託管控制器實例，其中將自動測試配置更改；

如果測試通過，拉取請求將合併到目標託管控制器的主分支中，以便更改生效。

這種方法解決了兩個關鍵挑戰。首先，它提供了一個自助式的自動化過程，開發人員可以通過該流程請求CI配置更改，無需面對機構官僚主義或追蹤管理員以請求更改。其次，基於Git的方法可以確保在應用配置更改之前，對其進行了適當的測試和驗證。通過這種方式，開發團隊就可以避免引入導致流水線不穩定或不達標的更改的風險。開發人員也可以擁有他們所期望的個性化設置和穩定性。

下一篇文章，我們將為您帶來餘下三個挑戰的解決方案，包括排查流水線執行問題、管理流水線依賴關係以及構建基礎設施使用效率低下。並且，在下期文章的末尾，作者會給出她選擇的解決方案——一次解決這五種挑戰的核心武器，敬請期待！

作者：薩曼莎·弗羅斯特（Samantha Frost），CloudBees公司產品營銷經理。

文章來源：https://www.cloudbees.com/blog/lets-get-back-to-coding-5-appr...