現代軟體開發講求速度與效率，DevOps 和優異的開發者體驗至關重要。DevOps 強調開發和維運團隊的緊密合作，透過自動化流程、消除隔閡，實作更快速可靠的軟體交付。Git 作為分散式版本控制系統，讓開發者能有效追蹤程式碼變更、協作開發及管理版本。GitHub 則是一個根據 Git 的程式碼託管平台，提供豐富的協作功能、自動化工具和社群資源，進一步提升開發效率。本文將引導您瞭解 DevOps 的核心概念，並深入 Git 和 GitHub 的實務應用，包含分支策略、團隊協作流程以及如何整合 CI/CD，最終提升團隊生產力。此外，文章也探討了開發者體驗的重要性，以及如何透過 InnerSource 等協作模式，開發更開放、透明的開發文化，讓團隊成員更有效地貢獻和成長。
Git 與 GitHub 的實戰：DevOps 與開發者體驗
在現今快速變遷的軟體開發世界中，DevOps 和優異的開發者體驗已成為不可或缺的根本。DevOps 強調開發團隊和維運團隊之間的緊密合作，旨在消除隔閡、自動化流程，並以更快速、更可靠的方式交付軟體。
DevOps 的背景故事
DevOps 的起源可以追溯到敏捷開發的興起。傳統的開發和維運團隊之間的隔閡阻礙了快速迭代和持續交付的目標。DevOps 的出現彌合了這一鴻溝，促進團隊之間的協作，並將自動化融入到軟體交付的每個環節。
DevOps 的誤區
許多人誤以為 DevOps 只是單純地使用自動化工具或採用某種特定的技術。DevOps 的核心在於文化和理念的轉變，需要團隊成員之間的相互理解、信任和合作。
DevOps 文化的重要性
DevOps 文化強調團隊合作、持續改進和自動化。它鼓勵團隊成員積極溝通、分享知識，並共同承擔責任。這種文化上的轉變是 DevOps 成功實施的關鍵。
Git 與 GitHub：現代開發的利器
Git 是一個分散式版本控制系統，讓開發者能夠輕鬆地追蹤程式碼的變更、協作開發，並有效地管理程式碼版本。GitHub 則是一個根據 Git 的程式碼託管平台，提供了豐富的協作功能、自動化工具和社群資源。
Git 的歷史
Git 的誕生源於 Linux 核心開發的需求。它最初由 Linus Torvalds 開發，旨在提供一個高效、可靠的版本控制系統，以支援全球範圍內的協作開發。
GitHub：AI 驅動的開發者平台
GitHub 不僅僅是一個程式碼託管平台，更是一個 AI 驅動的開發者平台。它提供了豐富的功能，包括程式碼審查、問題追蹤、專案管理、CI/CD 等，旨在提升開發者的生產力和協作效率。
掌握 Git 與 GitHub：開啟 DevOps 之旅
這篇文章將引領您進入 DevOps 的世界，並探討 Git 和 GitHub 在現代軟體開發中的關鍵角色。從 Git 的基礎知識到 GitHub 的進階功能，我們將逐步揭開這些工具的神秘面紗。
文章涵蓋的內容
- DevOps 與開發者體驗：介紹 DevOps 和開發者體驗在現代軟體開發中的重要性，以及 Git 和 GitHub 如何提升開發流程。
- Git 基礎入門：提供 Git 的實用入門，涵蓋檔案管理、分支和團隊協作原則。
- GitHub 團隊協作：探討 GitHub 在 DevOps 中的角色，涵蓋團隊合作和協作功能，以及如何從傳統系統過渡到現代 DevOps 實踐。
圖表翻譯： 上面的 Plantuml 圖表展示了文章的內容架構，從 DevOps 和開發者體驗的介紹開始，逐步深入 Git 和 GitHub 的使用，最後探討 AI 在軟體開發中的應用以及對未來的展望。
現代軟體開發的根本：DevOps 與開發者體驗
本章將探討兩個核心主題：DevOps 和開發者體驗。DevOps 將開發和營運團隊融合為一個整體，分享文化、最佳化流程、並運用各種工具，以加速發布、提升產品品質。
DevOps 的真諦
DevOps 是人員、流程和工具的結合，旨在持續為終端使用者提供價值，這從根本上是一種文化轉變。
圖表翻譯： DevOps 整合了人員、流程和工具，共同為終端使用者創造持續價值。
DevOps 的常見誤區
許多人誤以為 DevOps 只是單純地使用自動化工具或採用某種特定的技術。DevOps 的核心在於文化和理念的轉變，需要團隊成員之間的相互理解、信任和合作。
程式碼範例
def hello_world():
print("Hello, World!")
hello_world()
上述 Python 程式碼定義了一個名為 hello_world 的函式，當呼叫該函式時，它會列印出 “Hello, World!"。這是一個簡單的範例，用於展示如何定義和呼叫函式。
打破孤島：DevOps 文化的精髓與實踐
在軟體開發的世界裡，敏捷（Agile）和 Scrum 已經深入人心，那麼 DevOps 是它們的進化版嗎？或者說，DevOps 包含了它們嗎？答案並非簡單的肯定或否定。DevOps 的視野更廣闊，它不僅關注軟體開發，更涵蓋了軟體發布、收集反饋和持續改進，這些原則貫穿整個軟體開發生命週期（SDLC）。團隊的焦點放在產品的整個生命週期，而不僅僅是開發新功能或設計網頁元件。
圖表翻譯： 上述 Plantuml 圖表展示了 DevOps 生命週期的八個階段的迴圈流程，從規劃到監控，每個階段緊密相連，形成一個持續改進的迴圈。
然而，DevOps 的最終目標並非引入一個全新的流程。DevOps 擁有廣泛的實踐，但並非所有實踐都適用於每個團隊。例如，需要將應用程式佈署到大量伺服器的環境與將小型應用程式佈署到單個 EC2 例項的情況截然不同。同樣，服務百萬使用者的系統和服務千名使用者的系統，其適用的實踐也大相徑庭。
正如 Andy Hunt 在其部落格中對敏捷的詮釋：「敏捷方法要求從業者思考，坦白說，這並不容易推銷。僅僅遵循既定規則並聲稱『按部就班』要舒服得多。這很簡單，也很安全，不會招致嘲笑或指責；你不會因此被解僱。雖然我們可能會公開譴責規則的狹隘限制，但規則之中卻有著安全和舒適。當然，敏捷或高效並非為了舒適。」
這個理念同樣適用於 DevOps。為了頻繁與快速地發布以客戶為中心的開發成果，提供可靠的服務，並最終對業務產生重大影響，你需要從更廣泛的視角來解決問題，而不僅僅是工具、人員和流程。
DevOps 是一種文化
DevOps 不僅僅是開發和維運的融合，也不僅僅是特定的角色、流程、工具、技術或產品。人們常常將其簡化為人員、流程和工具，但 DevOps 的真正含義是什麼？
讓我們參照 DevOps 社群的傑出人物 Patrick Debois 的話來闡明：「我目前對 Dev*Ops 的定義是：你為克服孤島效應所做的所有事情……剩下的只是普通的工程。」
在當今的雲端技術時代，無論是尖端科技公司、傳統企業還是新創公司，都可以輕鬆取得相同的環境。即使是根據人工智慧的工具，也能以合理的價格獲得。
最終，阻礙團隊和業務進展的是摩擦，而這種摩擦通常產生於包含人員、流程和工具的孤島之中。DevOps 的核心是一種文化轉變，旨在消除組織內孤島之間的摩擦。它需要思維方式、習慣和文化的轉變。
DevOps 的原則
那麼，DevOps 文化究竟包含哪些內容？讓我們探討 DevOps 的核心原則，以更全面地理解這種文化的真正內涵。
以客戶為中心
每個流程中的每個行動都應以向客戶提供價值為目標。在構建和維護軟體時，以客戶為中心可以更快、更準確地交付功能。短反饋迴圈有助於根據使用者需求微調產品，降低風險，並以最低的成本實作價值最大化。透過關注客戶需求，最終目標變成了有效解決現實世界的問題，從而更容易確定任務優先順序、管理待辦事項和簡化資源分配，使維運高效與經濟。最終，透過更好地滿足市場需求和使用者期望，為長期的業務成功奠定基礎。在 DevOps 中，以客戶為中心不僅僅是一句口號，而是一種必需。
從結果出發進行創造
瞭解客戶需求並解決現實世界的問題應該優先於根據假設的運作。這提倡一種整體策略，團隊同步開發和維運任務以滿足客戶需求。這包括掌握產品的整個生命週期，從其初始構思和開發到佈署和持續支援，確保最終交付成果真正造福最終使用者。
跨職能的自主團隊
成功實施 DevOps 的核心是組建自主的跨職能團隊。這類別團隊具備多種技能，從編碼和測試到佈署和設計，甚至對業務有深入的瞭解。決策速度因此加快，用快速、負責任的行動文化取代了等級森嚴系統中固有的緩慢而繁瑣的指揮鏈。消除這些組織瓶頸不僅可以加快工作流程，還可以培養主人翁意識和責任感。
持續改進
持續改進是 DevOps 的根本，它提供了技術和文化優勢，對於現代軟體開發和維運來說不可或缺。在技術方面，它透過持續分析效能指標和利用自動化工作流程，實作軟體交付流程的可靠性、適應性和效率等品質。在文化方面，持續改進營造了協作環境，確保責任制，鼓勵學習文化，並最終有助於打破組織孤島。
打破藩籬：DevOps 的進化與最佳實踐
在傳統軟體開發模式中，開發和營運團隊如同兩個獨立的個體，開發人員專注於編寫程式碼和構建應用程式，而營運人員則專注於佈署和維護。這種割裂的工作方式往往導致專案延遲、效率低下，以及團隊間的摩擦。
持續整合/持續交付（CI/CD）的出現，如同橋樑般連線了開發與營運。CI 讓來自不同開發者的程式碼頻繁地合併到分享儲存函式庫中，並透過自動化測試及早發現錯誤和不一致之處。CD 則確保程式碼隨時可以佈署，消除了冗長的程式碼凍結期。
自動化不再是錦上添花，而是不可或缺的要素。自動化指令碼負責從程式碼測試到佈署的各種任務，確保流程標準化，消除許多人工干預帶來的錯誤和延遲。
DevOps 的概念不斷演進，一些新的概念和實踐應運而生，例如 DevSecOps、IaC 和可觀測性，這些概念豐富了 DevOps 的內涵，也為現代軟體開發帶來了新的可能性。
安全至上：DevSecOps 的崛起
DevSecOps 將安全性融入 DevOps 架構中，從開發的初始階段就將安全性視為關鍵要素。過去，安全性通常由獨立的團隊負責，而往往在開發週期的後期才介入，導致漏洞在開發後期才被發現，造成軟體釋出延遲。
DevSecOps 倡導「左移」安全策略，在設計和開發階段就開始解決安全問題，主動防禦而非被動反應，確保應用程式在設計上就具備安全性。
圖表翻譯： 上述 Plantuml 圖表展示了軟體開發的不同階段，以及在不同階段修復缺陷的成本差異。在早期階段修復缺陷成本較低，而在後期階段修復成本顯著增加。
DevSecOps 將安全性視為一種持續的狀態，而非終點。透過自動化工具確保持續的安全性，可以快速應對新發現的漏洞。
基礎設施即程式碼（IaC）
IaC 透過程式碼管理和組態系統基礎設施，包括網路組態和伺服器設定。過去，伺服器設定和網路組態等任務通常由人工手動執行，不僅耗時費力，還容易出錯。IaC 則透過自動化組態管理軟體，將基礎設施的狀態定義為程式碼，自動應用組態，消除了繁瑣的手動工作，確保了高水準的可重複性和一致性。
全面洞察：可觀測性的力量
可觀測性是管理現代軟體系統的關鍵組成部分，它超越了傳統監控的範疇，提供了對系統整體健康狀況的全面洞察。可觀測性依賴於指標、日誌和追蹤（也稱為遙測資料）來提供系統效能的全面關聯圖。
圖表翻譯： 上述 Plantuml 圖表展示了可觀測性的三大支柱：指標、日誌和追蹤，它們共同構成了對系統狀態的全面理解。指標提供了系統效能的量化資料，日誌記錄了系統中的事件和錯誤，而追蹤則幫助我們瞭解請求在系統中的流轉過程。
開發者體驗：DevOps 持續成功與成長的關鍵
在理解 DevOps 的基本概念、文化以及組成要素（如 DevSecOps、IaC 和可觀察性）之後，下一個挑戰是如何讓 DevOps 在組織內持續成功並成長？
或許你會遇到這樣的情況：「我們擁有一支優秀的 DevOps 團隊，合作良好，文化也大幅改善！」但正當你覺得一切趨於完美時，經驗豐富的工程師卻紛紛離職，去尋求更好的機會。
這凸顯了一個重要的問題：如何保持 DevOps 團隊的活力和成長？這不僅需要技術上的支援，還需要良好的開發者體驗。只有當開發者感受到被重視、被支援，並且能夠在一個高效、協作的環境中工作時，才能夠長期保持高昂的工作熱情和創造力，從而推動 DevOps 的持續成功與成長。
開發者體驗：卓越開發的策略
開發者體驗不僅僅是使用者經驗，它包含 DevOps 團隊中的開發者如何高效工作並對工作感到滿意。這也是組織 DevOps 成功的策略。如果工程師快樂，組織內部沒有孤島，溝通順暢，DevOps 就會成功。在這個方面，GitHub 本質上是一個最大化開發者體驗的平台，而 Git 是實作這一目標的手段：
圖表翻譯：
此圖示闡述了開發者體驗與 DevOps 成功之間的直接關係。開發者體驗是促進 DevOps 成功的關鍵因素。
當你關注 DevOps 領域中的個別工具時，它們可能看起來微不足道。然而，從維持和實作 DevOps 成功的角度來看，開發者體驗與如何使用 Git 和 GitHub 之間的聯絡變得更加緊密，因為這是開發者進行重要溝通的地方。
開發者體驗是一種策略
開發者體驗的本質是創造一個讓開發者能夠發揮最佳水平的環境。在 DevOps 的背景下，開發者體驗可以被解釋為一種策略，用於在組織中創造、發展和維護最佳的 DevOps 文化。DevOps 完全關乎文化。如果你的開發團隊不滿意，就不要期望蓬勃發展的文化。沒有蓬勃發展的文化，DevOps 也無法蓬勃發展。
根據 GitHub 的說法，開發者體驗的概念可以用以下公式表示：
圖表翻譯：
此圖示展示了 GitHub 定義的開發者體驗公式。它包括四個主要元素：開發者生產力、開發者影響力、開發者滿意度和協作，共同構成了開發者體驗。
公式中的每個元素可以解釋如下：
- 開發者生產力： 代表效率和速度。換句話說，它反映了開發者完成任務的效率和速度。
- 開發者影響力： 包括影響、實施程式碼變更以及從構思到生產。它說明瞭開發者的影響範圍以及他們將想法轉化為實際產品或服務的速度。
- 開發者滿意度： 表示在工作環境、工作流程和工具中以低摩擦實作高影響。它主要衡量開發者對工作的滿意度、工作流程的順暢程度以及他們使用的工具的有效性。
- 協作： 會放大這些元素。團隊內的合作和溝通越好，開發者的生產力、影響力和滿意度就越高。
現在讓我們探討一下這些元素如何為 DevOps 基礎服務。
提升開發者體驗：邁向卓越開發的策略
衡量開發者的貢獻，最簡單的方法是量化其對產品最終價值的影響。例如，如果團隊正在開發新功能，其影響可以透過新功能吸引的使用者數量和產生的收入來衡量。其他指標包括下載量、請求數、服務等級協定（SLA）等。良好的 DevOps 文化能提升工程師的幸福感。
在 DevOps 領域，關注點通常集中在團隊如何影響客戶和整個業務。這個領域的指標通常從產品或客戶開始，例如衡量佈署的頻率。相比之下，開發者體驗則關注開發者，強調他們對程式碼函式庫和最終投入生產的想法的影響。
開發者生產力
提高開發者生產力是一項複雜的挑戰。DevOps 就像催化劑，它可以消除組織的低效率，提高開發團隊的產出。
def calculate_productivity(time_saved_per_day, num_developers):
"""
計算團隊每天節省的時間總量。
:param time_saved_per_day: 每位開發者每天節省的時間（分鐘）
:param num_developers: 團隊中的開發者人數
:return: 團隊每天節省的時間總量（小時）
"""
total_minutes_saved = time_saved_per_day * num_developers
total_hours_saved = total_minutes_saved / 60
return total_hours_saved
# 示例用法
time_saved = 10 # 分鐘
num_devs = 100
productivity_gain = calculate_productivity(time_saved, num_devs)
print(f"團隊每天節省的時間：{productivity_gain} 小時")
內容解密：
此程式碼範例展示瞭如何計算團隊每天因提高生產力而節省的時間總量。它接受每位開發者每天節省的時間和團隊中的開發者人數作為輸入，然後計算出團隊每天節省的時間總量（以小時為單位）。這個簡單的計算有助於理解小幅度的效率提升如何在整個團隊中累積，從而顯著提高整體生產力。
開發者影響力
衡量開發者影響的指標有很多，但最容易採用的指標包括開發者關閉提取請求所需的時間，以及收到客戶反饋到實際實施之間的時間跨度。
開發者滿意度
最重要的是，在這種情況下，開發者生產力和影響力並不是為了讓管理者管理和指出個別開發者的生產力，而是為了幫助開發者以更積極的方式加速開發。
組織需要確保其工程師透過開發和交付價值給客戶，並擁有最佳的環境、工作流程和工具來滿足他們。
協作
在強化 DevOps 成功所需的開發者體驗方面，協作是關鍵。這不僅僅是整合開發團隊和基礎架構團隊並分擔一些責任；而是要創造一個環境，讓開發者能夠蓬勃發展、做出貢獻，並感受到主人翁意識和參與感。
@startuml
skinparam backgroundColor #FEFEFE
title Git 與 GitHub：釋放 DevOps 的力量
|開發者|
start
:提交程式碼;
:推送到 Git;
|CI 系統|
:觸發建置;
:執行單元測試;
:程式碼品質檢查;
if (測試通過?) then (是)
:建置容器映像;
:推送到 Registry;
else (否)
:通知開發者;
stop
endif
|CD 系統|
:部署到測試環境;
:執行整合測試;
if (驗證通過?) then (是)
:部署到生產環境;
:健康檢查;
:完成部署;
else (否)
:回滾變更;
endif
stop
@enduml圖表翻譯：
此圖示闡述了開放性如何透過降低進入門檻和提供清晰的檔案來提升開發者體驗。開放性和透明度是 InnerSource 的核心原則，它們有助於消除組織內的障礙，使開發者更容易參與專案並作出貢獻。
DevOps 與開發者體驗：進入現代開發的世界
DevOps 不僅僅是工具和實踐；它是一種文化、一種哲學，也是一個旨在實作業務和組織成功的概念。在這種情況下，Git 和 GitHub 通常被邊緣化為僅僅是工具或溝通方式。這種觀點有時是正確的，但通常是短視的。當您打算學習 Git 和 GitHub 以用於 DevOps 時，採用這種觀點可能會將您的理解限制在僅僅是個人方面，例如何使用 GitHub Actions 進行 CI/CD 或如何使用 Git 和 Git 分支策略。
促進這種協作的最有效範例之一是 InnerSource。InnerSource 借鑒了開源協作模型，使組織內的開發者能夠為他們並非正式成員的其他團隊的專案做出貢獻。就像在開源開發中一樣，InnerSource 鼓勵公開溝通、程式碼分享和集體解決問題，有效地減少了經常困擾組織的孤島。
InnerSource – 去中心化貢獻模型
InnerSource 的靈感來自開源世界，但它旨在透過在組織邊界內應用開源實踐來解決內部工程挑戰。它允許跨團隊協作和分享技術專業知識，最重要的是，它旨在創造一種更透明和更具包容性的文化。
InnerSource 的四大支柱
- 開放性： 開放性消除了組織內任何工程師的進入壁壘。清晰的檔案使專案易於發現和存取。
- 透明度： 當我們談論 InnerSource 中的透明度時，指的是專案決策的公開性。例如，問題對話和提取請求審查都是透明地進行的，通常都有記錄，並且易於存取。
- 優先指導： 這涉及確保貢獻者獲得指導和支援，以便他們能夠有效地參與專案。
- 自願程式碼貢獻： InnerSource 鼓勵自願的程式碼貢獻，這有助於提高參與度和動力。
透過實行 InnerSource，原本孤立的團隊可以開始合作，共同解決問題，從而提高整體的 DevOps 成熟度和成功率。這種方法不僅促進了技術上的協作，還培養了一種更加開放和包容的文化，這對於現代 DevOps 環境至關重要。
