本次会议讨论了如何根据公司需求建设GitLab DevOps流水线，强调了文化、资源和技术适配的重要性。演讲者分享了多年的经验，建议在推进新技术之前要充分了解公司的现状和需求，同时考虑资源的有效利用。通过引入DevOps文化，可以提高组织效率和应对变化的能力。

1. 從觀察到實踐：
打造符合公司需求的
GitLab DevOps 流水線
( 聽大神的話建立 DevOps 流水線 )
2024-09-13 | 10:25 - 11:05
6F BC 會議室

2. About me
愛好咖啡及視覺系搖滾音樂
總是想辦法用最省事的方式來解決問題的懶惰工程師
曾任職於電商電信業十餘年工作經驗
2018~
AWS User Group aws notification system
使用 建立
Serviceless All-star 秒發百萬推播
ModernWeb Graph Database應用思考模式
PHP 也有 Day
PHP+ETL+Serverless
爭什麼， 摻在一起做成撒尿牛丸啊
2019~
ModernWeb 使用 Pentaho Kettle ETL 做系統資料後盾
COSCUP 用 ETL Kettle 打造程序流水線
2020~
COSCUP 使用開源資料庫 arangoDB 的奇幻之旅
Taiwan Cloud Summit 用 Serverless 真的方便又省錢 ?
2023~
DevOps Taipei 使用 Robot Framework 實踐
BizDevOps

3. 您好 ~~ 我新來的 !
來這邊是要做 DevOps 相關工作
( 兼開發工程師 )
( 兼 MIS)
( 兼 TechPM)
( 兼顧資安 )

4. 這些要一個人做嗎 ? 別鬧了 !
DevOps 是文化
主要是確認每個環節操作順暢性及必要性

5. 別急著動手啊 ~~~!!! 先看看你在處在什麼資訊環
境
● 公司用甚麼管理程式 ?
● 使用的程式語言是什麼 ?
● 大家有在做測試嗎 ?
● 現在有流水線嗎 ?
● ...........
GitLab
C++, C#, python
完全沒有
完全沒有

6. 別急著動手啊 ~~~!!! 先看看你在處在什麼公司環
境
● 公司是賣什麼的 ?
● 大家用什麼方式溝通 ?
● 交付的週期誰決定 ?
● 用什麼方式來看軟體版次 ?
● ...........
Windows 軟體
+Server
Line + Jandi
有訂單才交付
Excel 人工填寫

7. 蝦米 !! 版本控制號碼沒人看得懂 !?
Before
● v1.0
● V2R1
● 1.2437.2
● 1.2.3a
● 1.2.3_tab
● .....

8. Semantic Versioning 語意化版本
- 主版本號（ MAJOR ）：當進行了不兼容的 API 修改時，增加主版本
號。
- 次版本號（ MINOR ）：當增加了新功能時，增加次版本號。
- 修訂號（ PATCH ）：當進行錯誤修復時，增加修訂號。
變形 !!!! 2437.1.2.3
迷之音 : 我看版號不知道是甚麼時間點釋出的阿 ~~
1.2.3

9. 2437.1.2.3
1.0.1
2.1.4
1.6.8
After

10. 別急著喊口號 ~~~!!! 先看看大家接受新技術的態度
績效預期
努力預期
社群影響
便利條件
年齡 性別 經驗
行為意向

11. 再等一下啊 ~~~!!! 看看你能運用的資源有哪些
● 硬體資源
● 變更權限
● 教學資源
● ...........
一台 3080 工作站桌機 + 一台
NAS
雲端硬碟無權限 + NAS 無 ROOT 權
限
工程師要自己學沒補助

12. 找個類似主題的圖
準備好的戰役才有勝算的機會

13. 工程師
開發
自動
編譯
沒有測試
有的話更好
釋出
版本號
將安裝檔
放到公開位置
客戶端安裝
聽聽有無
BUG 回報
需求與 BUG
收集評估

14. 流水線重要嗎 ? 讓它更重要一點吧 !

15. BizDevOps 誰說得算 ?
老
闆
工
程
開
發
維
運
客
服

16. 加入軟體開發週期
(SDLC) 說詞
有沒有感覺跟前面
的內容很像

17. 再加入產品路線圖（ Product Roadmap ）說法
產品願景
業務目標
時限
主題
免責聲明
客戶價值（畫大餅）
想要實現的商業目標
(Business case)
時程脈絡
聚焦開發主軸並
排序優先順序
可能的限制和免責事項

18. V-model
需求
概約設計
詳細設計
功能設計
系統開發
單元測試
整合測試
驗收測試
功能測試
規劃 分析 驗證 測試
客戶需求的確認
內部確認

19. 資料來源 : VS.
瀑布 敏捷：必須知道的差異

21. 最終流水線如何與商業價值結合
需求與 BUG
收集評估
分析真需求
假議題
破壞性創新
或傳統功能
專案計畫
介面設計

22. 把研討會大神們介紹過的工具
直接搬來使用 ?

23. 你確定你學的完這些嗎？這些軟體適合你的公司
嗎 ?

24. 技術需要考量的地方
● 你很會這些嗎 ?
● 大家都會這些嗎 ?
● 要你教大家 , 你行嗎 ?
● 維運的成本
gitlab-ci 略懂略懂
沒人會 , 還要幫大家寫
除了既有工作還要邊學
邊寫教學文件
調整的話要花多久時間

26. 舊東西又如何 ? 用的順才是王道 !

27. 前輩建的古老 BUG 追蹤系統 ,
但流程完善又與 GITLAB 有銜接
有限資源下又能有控制權的方式
弱點掃描檢視程式弱點 ( 社群版 )
為了放安裝檔找的檔案管理軟體
能跟 AWS S3 串接的檔案管理軟體

28. 多去理解新科技新技術
但不要急著導入

29. 允許範圍內偷用一點新東西 增加自己技能
● AWS Serverless
○ Jandi notify
○ Line notify
● 資安掃描
○ SonarQube
○ Greenbone
● OpenSource
○ 檔案管理

30. DevOps 變成的形狀

31. 文化需要考量的地方
● 有資源讓你建系統嗎 ?
● 公司現有的規模適合嗎 ?
● 哪些要自動化 ? 哪些不要 ?
地端資源太少 , 用雲
端
殺雞不用牛刀
判斷哪些 1 年才做 1.2
次哪些是常常做的
哪些流程是常變化的

32. 加入點黏著劑
公司不能沒有你 ( 妳 ) 了 !

33. 有天公司說要導入 ISO27001.....
● 對銷售軟體的好處 ∶
○ 提高客戶信任度
○ 降低安全風險
○ 提升組織運營效率
○ 增加商業機會
● 對 DevOps 的影響 ∶
○ 安全需求納入每階段
○ 合規性和審計要求
○ 變更管理的強化
○ 持續監控和反應能力

34. DevOps 加入一些機制
● 人員控管
○ 密碼三個月改一次
○ 離職新進員工
● 主管檢核
○ 主管同意 ( 看過 ) 紀錄
● 備份
○ 排程備份所有系統資料
各系統串接 AD
(Active Directory)
串接 Jandi or Line
Crontab shell 備

35. 不能只有你一人來做啊 !

36. 如何做文件 ?
● GOOGLE 簡報 :
○ 不要 doc,ppt 檔案滿天飛
○ 共同編輯便利 , 可調整權限
○ 可看文件版本紀錄
● MediaWIKI :
○ 集中化的文件管理 ( 集中化目錄 )
○ 可控公開資訊與內部資訊

37. 未來的進化版文件
使用 RAG 檢索增強生成技術 ( 再多加點技能 )
資料來源 :
Accelerate performance using a custom chunki
ng mechanism with Amazon Bedrock

38. Stay hungry. Stay foolish.