雖然「GitLab 歷史與功能發展」快結束了，但我們先休息一次，今天來聊另一個延伸話題。

在昨天的文章中，我有聊到 GitLab 收購了 UnReview，並且還做了一年回顧來宣示他們跨入 ML / AI 的決心。

其實在原廠的 Product Stage Direction 中，還有一個頁面更詳細的說明了 GitLab 原廠想要將產品擴大到 ML/AI 領域到決心，甚至將這個方向稱之為 ModelOps。

很可惜的是這個 Direction - ModelOps 的網頁，剛好在 10 天前（2024/09/20）被 Clean up 了，所以現在連上去已經看不到我當初讀到的精彩內容。（如果你真的想看，還可以透過留在 GitLab Project 上的歷史紀錄查看。）

下面就分享我當初在原廠的 ModelOps 產品發展方向中，看見的一些重點

產品發展方向的重點：

• GitLab 的 Vision 是成為一個 ALLOps 的平台，服務任何的 R & D。
• 2024 鎖定的就是目標對象即是資料科學家，讓 GitLab 也能滿足 DataOps 與 MLOps 的需求。
• 降低資料科學家的工作場景中的複雜性，讓資料科學家也可以像其他軟體工程師一樣，在 GitLab 單一平台上輕鬆的開發、管理與交付自己的產出。
• 讓既有的 CI/CD Pipeline 功能，不只能適用於常見軟體的 Pipeline，也能適用於 Data / ML 領域。
• 續上，同時也意味著，GitLab 不只能滿足軟體開發的 SDLC，也能滿足 Data / ML / AI 領域的「開發生命週期」
• 同時，GitLab 也看上了資料科學、資料驅動、AI / ML 的潛力，希望利用這些 Data / ML / AI 改善並提升 GitLab 既有的產品功能。

針對資料科學家的困境：

• 資料科學家並非軟體工程師，但是他們同樣也會遇到軟體開發領域常見的問題，軟體開發、軟體交付、軟體部署、軟體維運、系統維運、Pipeline 維護、Infra 建置⋯⋯
• It works on my machine 的狀況，也同樣會發生在資料工程師與資料科學家身上，甚至狀況可能會更嚴重。因為很常見的狀況是，資料科學家只需要一個 Jupyter notebook 就做完一切的事情，下至 infra 上至安裝了哪些軟體、套件、寫了程式碼、產出哪些 Data，全都在資料科學家自己的電腦，或是那一台超強的實驗室主機上完成。
• 在 DevOps、DevSecOps 我們發現的 silos，在 Data Team 也會是一個大問題，知識、資訊、工具、產出的交接與傳遞並不順暢。

GitLab 原廠做了哪些事：

• 從 2022 年開始積極的開發 ML / AI 相關的功能
• 吃自己的狗食，嘗試在內部實驗運用 ML / AI。
• 讓 GitLab Runner 支援 GPU
• 探索 Data / AI / ML 領域的潛在合作夥伴（收購對象）

DevOps、DataOps、MLOps，這三種 OOXXOps 全都是流程、人、工具糾葛在一起的議題，甚至是這三種 OOXXOps 本身就彼此糾葛。Data 在企業內先天就是一種會貫穿多個單位、部門、團隊、系統、工具的「產出物」，DataOps 很難不碰觸到 DevOps 軟體開發領域，而需要 Data 來訓練與開發模型的 MLOps 也是如此。這樣看來，GitLab 作為一個已站上 The One DevOps / DevSecOps Platform 的產品，繼續擴大守備範圍，成為那個可以貫穿組織內部溝通協作的大平台，確實是一個合適的發展方向。

圖片來源 - 吉卜力工作室 https://www.ghibli.jp/works/totoro/#&gid=1&pid=27