過去，企業或組織所打造的 DevOps 團隊，常常是 Dev 開發人員兼顧維運任務，或 Ops 系統人員跨域撰寫程式碼，從而演變成一條龍服務。有鑑於此，從而演變出 SRE 團隊，能夠跨越開發和維運兩者之間，穩定企業和組織的營運服務，使 DevOps 團隊能專注於整體流程。

在 IaC 基礎架構及程式碼方面，也逐漸從過去 Push/Pull 架構之爭，演變為全自動化且信任唯一來源的 GitOps 運作架構。

因此，在本工作坊中，將讓與會人員了解，SRE 的基本功，透過建構自助式服務，解決 Day 1 Operations 工作任務，將常態性或重複性的工作任務自動化，舉凡 VM 虛擬主機的部署，或是容器服務的調度……等，同時也將半自動的 IaC 基礎架構及程式碼服務，提升為全自動的 GitOps 流程，進而處理 Day 2 Operations 的工作任務，例如，營運服務的生命週期、監控、修補臭蟲……等，甚至整合 Event-Driven 事件驅動機制，達到主動式或被動式自動回應機制。

1. 分支策略與Pipeline流程規劃：介紹程式主要的分支策略與CI/CD的劃分，這是整體設計的核心框架。骨架弄好就不怕後面的設計散掉。
2. YAML範本與階層架構：DevOps執行CI/CD的血與肉，透過整理出來共同的模式可以設計為範本，同時在面對多種不同的系統時又能擁有部份自定義的彈性。
3. DevOps之下的設計原則：不論是舊的系統或是新開發的系統，轉型與創新的路上都必須遵照某些設計的原則進行，例如：機敏性設定抽離、編譯一次用在n個不同環境、容器化優先、Dockerfile與Pipeline YAML與系統程式碼版控分離等。
4. Project與Repository的考量：Azure DevOps可以為每一個系統建立一個獨立的Project，擁有完整的功能。但，真的需要嗎？或許每個系統使用一個Git Repository更適合？分享我的管理經驗談。
5. 跨組織引用Pipeline YAML設計：不管是企業內部部署Azure DevOps Server中的集合或是雲上的組織，在不大動千戈的情況下想要引用YAML範本怎麼做比較好？
6. 面對使用者的經驗之談：沒有人一開始就會使用，面對複雜的系統或流程，先讓使用者能從簡單的流程做法開始，然後再…

上面六個主題為演講大綱，除了簡報內容與經驗分享之外，也會包含部份實做環節(2與5)。

• 什麼是合約測試？包含與傳統測試的區別（如端到端測試、單元測試），並瞭解合約測試的優勢
• Pact，合約測試框架介紹，了解其設計驅動性，以及核心組件的架構與職責
• 以 Web 為例，我們怎麼實作合約測試，並以 Component 為單位推動
• 怎麼在 CI/CD 中整合合約測試，以 Github Action 為例

一切的改變都是從 commit 開始，而這件事情理應像 event driven system 一樣自然而然的驅動後續的所有事情，自動連結 Jira issue，從此不用因為 commit message 寫了一堆 "fix"、"fix again"、"finally fix" 而困擾，以及自動的從一堆 commit 中生成有意義的變更紀錄（編年史），自動生成 SemVer 版號幫 docker image 打 tag （建構出一個有版本的世界），接著就是如何在獨立環境重現各種不同版本的微服務互動的整合測試（部署多重宇宙）。

目標聽眾：

覺得 commit 紊亂的，覺得每次要想版本號很困難的，覺得 commit message 很沒有用不知道到底為了什麼而做的，很難在隔離環境重現問題的。

本Session將介紹由DX公司CEO Abi nods及維多利亞大學教授Margaret-Anne Storey、微軟研究院合夥人Nicole Forsgren和DX研究負責人Michaela Greiler所共同撰寫的DevEx開發者體驗衡量框架。這一框架在著名的IEEE和ACM Queue 雜誌上發表後(2023/01)，再次掀起了如何衡量工程師產能的討論熱潮。無論你是否懷疑產能測量的準確性，這篇文章中的許多觀念確實值得任何開發團隊關注。深入了解這些觀念後，或許能引發你更多的聯想，對自己的開發效能帶來更顯著的幫助。

開發者體驗（DevEx）衡量框架的核心在於提供一套系統化的方法，幫助團隊評估和提升開發者的工作體驗。這不僅僅涉及到開發效率和產能，還包括開發者在工作過程中的滿意度和幸福感。研究顯示，優良的開發者體驗能顯著提高團隊的創造力和生產力，並降低員工流失率。透過這個框架，團隊可以更有效地識別和解決影響開發效能的瓶頸，進一步提升整體開發流程的效率和質量。這些觀念和方法，不僅適用於大型企業，同樣也適用於中小型開發團隊。

過去，企業或組織所打造的 DevOps 團隊，常常是 Dev 開發人員兼顧維運任務，或 Ops 系統人員跨域撰寫程式碼，從而演變成一條龍服務。有鑑於此，從而演變出 SRE 團隊，能夠跨越開發和維運兩者之間，穩定企業和組織的營運服務，使 DevOps 團隊能專注於整體流程。

在 IaC 基礎架構及程式碼方面，也逐漸從過去 Push/Pull 架構之爭，演變為全自動化且信任唯一來源的 GitOps 運作架構。

因此，在本工作坊中，將讓與會人員了解，SRE 的基本功，透過建構自助式服務，解決 Day 1 Operations 工作任務，將常態性或重複性的工作任務自動化，舉凡 VM 虛擬主機的部署，或是容器服務的調度……等，同時也將半自動的 IaC 基礎架構及程式碼服務，提升為全自動的 GitOps 流程，進而處理 Day 2 Operations 的工作任務，例如，營運服務的生命週期、監控、修補臭蟲……等，甚至整合 Event-Driven 事件驅動機制，達到主動式或被動式自動回應機制。

[WHY] 為什麼從VM遷移到AWS EKS

• 遷移到AWS EKS的理由
• 更好的擴展性
• 成本效益
• 性能提升
• 增強的安全性
• EKS對企業的影響
• 自動管理和擴展容器化應用程序
• 降低維護成本
• 提高運行效率

[HOW] 建置工具在AWS EKS平台應用

• 部署和管理EKS集群的建置工具介紹
• `eksctl`
• AWS CLI
• AWS管理控制台
• 各項工具的使用情境
• 部署簡易性
• 管理方便性
• 優缺點比較
• 使用方便性 vs 功能完整性

[WHAT] 洞悉IaC與Terraform取得的應用優勢

• 基礎設施作為代碼（IaC）的管理
• 自動化部署過程
• 環境一致性
• 版本控制
• Terraform的應用案例
• AWS與Terraform的整合與實際應用

[WHEN] AWS外部服務與K8s組件實現整合

• EKS與不同AWS服務的整合
• IRSA (IAM Roles for Service Accounts)
• LoadBalancer
• EBS (Elastic Block Store)
• Monitoring（監控）
• 實際應用場景與整合設計架構
• 開發與應用案例

[WHERE] 深入EKS實務與Q&A

• 實際導入EKS的Web3.0專案經驗分享
• 安全性設計
• 可靠性保證
• 網路設計心得
• 互動問答環節

區塊鏈應用在旅行不便險與IAC部署在Azure DevOps

• 區塊鏈技術在旅行不便險中的創新應用
• 透明度與可追溯性
• 自動理賠與合約管理
• IAC在Azure DevOps中的部署實踐
• 持續整合/持續部署（CICD）的實現
• 自動化工作流與管理
• 企業應用案例分享

先描述 91APP 過去 Data team 的狀況，闡述什麼是 modern data stack 並且 modern data stack 如何幫助團隊解決現場面臨問題

當產品開發團隊從現場維運解脫後，會介紹產品開發團隊如何與業務協作共同衝刺業務目標，並且成功的達成業務目標推進的過程

當產生了 BizDevOps 的循環後，產品開發團隊如何針對現場開發方法去做改善，來加速產品開發的速度

DevOps已是顯學，聽了很多大神們在各技術研討會或網路社群中不斷教授其中的技巧，但家家有本難念的經，每間公司有各自不同的文化及流程，各家的流水線都會長的不一樣。 這次有個機會打造新的流水線，你會如何做?

1. 衝突最小化 : 現有文化觀察及資源盤點
2. 交付價值 : 以產品價值來考量設計"必要"的流程
3. 避免重複造輪 : 工具評估及選用的考量
4. 制度黏著 : 搭配公司制度, 補其"需要"的流程
5. 團隊建立與傳授 : 文件化並宣傳做法

隨著服務數量和團隊規模的增長，組織中的 CI/CD 流程管理變得越來越複雜。採用 Centralized CI/CD 策略能有效集中管理這些流程，確保一致性和可擴展性，並提高維運效率。

在本次議程中，我們將分享實施 Centralized CI/CD 策略的探索與精進經驗。內容將涵蓋以下幾個關鍵點：

• 架構設計：介紹 Centralized CI/CD 策略的整體架構。
• 挑戰與解決方案：探討初期遇到的挑戰和問題，以及相應的解決方案。
• 數據驅動的優化：如何利用數據分析持續優化 CI/CD 流程。
• 團隊協作與信任建立：通過一系列措施改善開發團隊與 CI/CD 團隊之間的對立和衝突，建立互信。
• 成功經驗與失敗教訓：分享具體的成功案例及從失敗中學到的教訓。

我們希望這次分享能幫助正在考慮或已經採用 Centralized CI/CD 策略的組織，從我們的經驗中獲得啟發，實現更高效的 CI/CD 管理。

本次演講將深入探討雲端多帳戶架構中實現GitOps的工具選型比較過程，特別是通過FluxCD與ArgoCD這兩大工具。

首先，我們將介紹GitOps的基本概念和其在現代雲基礎設施管理中的重要性。

接著，將分析雲端多帳戶架構的挑戰和機遇，並探討如何有效地在此架構下部署GitOps策略。

隨後，我們將對FluxCD與ArgoCD進行特性比較，包括它們的架構、易用性、成本。

最後，將提供實際案例研究，指導聽眾如何根據自身需求選擇合適的工具。

在軟體開發的領域中，提升軟體品質已是成功的關鍵之一，而 DevOps 正是能幫助團隊達成這一目標的方法之一。在這場短講中，讓我們快速的認識 DevOps 及多項 DevOps 相關的實踐方法，了解它們是如何幫助我們提升軟體品質，明白 DevOps 與軟體品質有何關聯性。DevOps 不僅僅是技術工具的組合，它更是一種文化與流程的轉變，這條「持續改善」的道路，我們能獲得提升的將不只是軟體的品質而已。

這場短講我們不會深入探討每一項 DevOps 實踐方法，而是提供一個總覽，幫助聽眾明白原來在這些實踐方法的背後，有著一些共通的原則與目標。

1. 分支策略與Pipeline流程規劃：介紹程式主要的分支策略與CI/CD的劃分，這是整體設計的核心框架。骨架弄好就不怕後面的設計散掉。
2. YAML範本與階層架構：DevOps執行CI/CD的血與肉，透過整理出來共同的模式可以設計為範本，同時在面對多種不同的系統時又能擁有部份自定義的彈性。
3. DevOps之下的設計原則：不論是舊的系統或是新開發的系統，轉型與創新的路上都必須遵照某些設計的原則進行，例如：機敏性設定抽離、編譯一次用在n個不同環境、容器化優先、Dockerfile與Pipeline YAML與系統程式碼版控分離等。
4. Project與Repository的考量：Azure DevOps可以為每一個系統建立一個獨立的Project，擁有完整的功能。但，真的需要嗎？或許每個系統使用一個Git Repository更適合？分享我的管理經驗談。
5. 跨組織引用Pipeline YAML設計：不管是企業內部部署Azure DevOps Server中的集合或是雲上的組織，在不大動千戈的情況下想要引用YAML範本怎麼做比較好？
6. 面對使用者的經驗之談：沒有人一開始就會使用，面對複雜的系統或流程，先讓使用者能從簡單的流程做法開始，然後再…

上面六個主題為演講大綱，除了簡報內容與經驗分享之外，也會包含部份實做環節(2與5)。

1. 先說明背景，關於委外廠商開發專案的組成，接著會簡單說明在以往使用瀑布法會看到大概的里程碑，接著會帶入以往我們的做法即使遵照著ISO27001與CMMI等標準，會很容易不小心就落入了形式主義導致專案的失敗。
2. 接著帶入實戰上外包軟體開發專案很容易遇到溝通與項目追蹤不易，加上開發產物頻繁交付的門檻，進而導致預期不一致的狀況。在已知狀況下，以我們的案例的痛處去分析可能的解決方案。
3. 解決方案其實就是一種改革，通常會影響的範圍會非常廣，可以透過POWERS (Proccess、Objective, window, evalute , relation and structure)框架來進行各面向的分析。
4. 由於改革會遇到痛處，也會造成各種內外力的影響，因此建議以試辦先行，並提供經驗中試辦案需要挑選的人員與專案類型，以降低改革失敗的機率。
5. 對試辦案中的同仁以及外包商專案成員，由於會需要做一系列的改變，因此引入ADKAR說明一系列改革建議的循環模式，以促進成員對於改變的發生。
6. 以實例的三個案例，並輔以驅力與阻力的力場圖，來說明我們專案中如何一一克服每一次的改變。案例分別是：a.改變專案成員使用word檔案做為知識的保存方式，變更為使用wiki做為知識集中處。 b. 改變專以excel+email作為議題追蹤的保存方式，變更為使用board+userstory的行事作為紀錄、分析以及分派工作的統一來源。 c.改變外包商的開發交付模式，改以single source 的平台，使用Boards +Repo + Pipeline +PR 作為自動化交付邊界。並說明分支管理的做法，以及介紹工作可視覺化的流動，進而頻繁交付的模式建立。
7. 回顧我們里程碑的改變，且回顧前面簡報介紹到POWERS框架對高階長官承諾的改善事項，最後將改善事項評估的結果，以DORA指數來呈現成果。