DevOps的核心概念之一是CI/CD--持續(xù)集成和持續(xù)交付或持續(xù)部署栖榨，現(xiàn)在正在向機器學習運營（MLOps）邁進炎滞。CI/CD作為DevOps的核心實踐，通過簡化應用程序的構(gòu)建写隶、測試和部署到生產(chǎn)中衣式，擁抱工具和方法，可靠地交付軟件應用程序渤愁。讓我們在下面定義這些概念牵祟。
- 持續(xù)集成（CI）
是指每次用版本控制提交并推送到代碼庫（構(gòu)建應用程序）時，自動構(gòu)建和測試代碼的做法抖格。
- 持續(xù)交付（CD）
是將每次構(gòu)建部署到類似生產(chǎn)環(huán)境的做法诺苹，并在部署前對應用程序進行自動集成和測試。
- 持續(xù)部署（CD）
通過自動配置和部署應用程序到生產(chǎn)環(huán)境雹拄，用額外的步驟來補充持續(xù)集成收奔。
持續(xù)集成VS持續(xù)交付VS持續(xù)部署持續(xù)集成VS持續(xù)交付VS持續(xù)部署|源碼
過去幾年開發(fā)的大多數(shù)CI/CD工具都是專門為傳統(tǒng)的軟件應用程序而設計的。正如你（可能）知道的那樣滓玖，開發(fā)和部署傳統(tǒng)的軟件應用程序與構(gòu)建和部署機器學習（ML）應用程序在許多方面有很大的不同坪哄。那么問題來了。
- ML團隊如何采用現(xiàn)有的CI/CD工具來適應他們的機器學習用例势篡？
- 是否有更好的選擇翩肌，專門為ML應用而設計的？
在這篇文章中禁悠，你將了解到4個不同的團隊如何使用或已經(jīng)使用CI/CD概念念祭、工具和技術(shù)來構(gòu)建和部署他們的機器學習應用。本文的目的是讓你從這些團隊實施的不同解決方案中碍侦，對CI/CD的使用有一個廣闊的視角粱坤，包括他們的用例隶糕。
使用Azure DevOps進行機器學習（ML）的持續(xù)集成和交付（CI/CD）
在本節(jié)中，我們將介紹一個團隊的工作流程站玄，該團隊在Azure DevOps中為其機器學習工作負載協(xié)調(diào)了CI/CD流程若厚。他們的機器學習工作負載主要在Azure云上運行。
這個團隊幫助一個零售客戶使用機器學習以自動化的方式解決票據(jù)蜒什。當用戶提出票據(jù)或由維護問題產(chǎn)生的票據(jù)時测秸，機器學習被用來將票據(jù)分為不同的類別，幫助更快地解決票據(jù)灾常。
為了實現(xiàn)從開發(fā)到生產(chǎn)周期的自動化霎冯，該團隊利用Azure DevOps管道設置了構(gòu)建和發(fā)布任務。構(gòu)建管道從候選的源代碼和模型序列化（主要是使用ONNX）后钞瀑，生成模型工件沈撞。
使用發(fā)布管線將工件部署到基礎設施目標。發(fā)布管道在開發(fā)環(huán)境中測試后雕什，將工件轉(zhuǎn)移到質(zhì)量保證（或QA）階段缠俺。
模型測試發(fā)生在QA階段，團隊對模型服務進行A/B測試和壓力測試贷岸，以確保模型可以部署到生產(chǎn)環(huán)境壹士。
人工驗證者，通常是產(chǎn)品所有者偿警，確保模型通過測試躏救，得到驗證，然后批準使用發(fā)布管道將模型部署到生產(chǎn)環(huán)境螟蒸。
在將模型部署到生產(chǎn)環(huán)境后盒使，該團隊設置了cron作業(yè)（作為其CI/CD管道的一部分），每周監(jiān)測模型指標的數(shù)據(jù)漂移和概念漂移七嫌，以便在發(fā)生不可接受的漂移需要重新訓練模型時少办，可以觸發(fā)管道。
他們還通過檢查Azure DevOps Pipelines中的管道發(fā)布來監(jiān)控生產(chǎn)中的CI/CD管道的性能诵原。檢查的目的是為了確保他們的CI/CD管道是健康的英妓，處于穩(wěn)健的狀態(tài)。他們檢查CI/CD管道皮假，保持其健康和穩(wěn)健鞋拟，所遵循的準則包括。
- 定期審計系統(tǒng)日志和事件惹资。
- 集成自動化驗收測試。
- 要求對管道進行修改的拉動請求航闺。
- 在每個故事或功能被添加到管道之前褪测，對它們進行同行代碼審查猴誊。
- 定期報告對團隊所有成員可見的指標。
總而言之侮措，Azure DevOps為團隊提供了一套有用的工具懈叹，使這個項目的開發(fā)（機器學習；模型構(gòu)建）和運營團隊能夠和諧地工作分扎。
參考資料
- 本文涉及的python測試開發(fā)庫 謝謝點贊澄成！
- 本文相關(guān)海量書籍下載
- https://neptune.ai/blog/ways-ml-teams-use-ci-cd-in-production
使用Jenkins和Argo工作流程的GitOps的ML持續(xù)集成和交付（CI/CD）
為了實現(xiàn)CI/CD，團隊利用GitOps畏吓，使用Jenkins在測試環(huán)境中運行代碼質(zhì)量檢查和類似生產(chǎn)的煙霧測試墨状。該團隊有單一的模型代碼管道，每個拉動請求都要經(jīng)過代碼審查和自動單元測試菲饼。
拉動請求也要經(jīng)過自動化的煙霧測試肾砂，他們在那里訓練模型并進行預測，在一些小塊的真實數(shù)據(jù)上運行整個端到端的管道宏悦，以確保管道的每個階段都能達到預期的效果镐确，沒有任何問題。
對于模型的持續(xù)交付饼煞，在訓練完每個模型后源葫，會生成一份模型質(zhì)量報告，并由領域?qū)＜彝ㄟ^手動流程進行審查砖瞧，在得到領域?qū)＜业尿炞C并通過所有事先的檢查后臼氨，最終手動部署。
GitOps在一些常見的DevOps原則芭届、實踐和工具的基礎上储矩，采用了以Git為中心的方法。在GitOps中褂乍，存儲在存儲庫中的代碼和配置被認為是真理的源泉持隧，基礎設施會適應代碼的變化。GitOps幫助他們在亞馬遜EKS上以團隊所需的速度交付管道逃片，而沒有操作問題屡拨。
為了保持代碼質(zhì)量的一致性，他們把所有的代碼檢查都移到了包含模型代碼的Docker容器中褥实，所以代碼質(zhì)量檢查工具的版本和配置包括flake8呀狼、black、mypy损离、pytest都是統(tǒng)一的哥艇。這也有助于他們將本地的開發(fā)設置與Jenkins上使用的統(tǒng)一起來。
Docker確保他們不再有不同版本的依賴關(guān)系的問題僻澎，這可能導致本地和Jenkins或生產(chǎn)中的不同結(jié)果貌踏。
對于本地開發(fā)十饥，他們有一個Makefile來構(gòu)建Docker鏡像，并在代碼上運行所有的檢查和測試祖乳。
對于代碼審查逗堵，他們設置了Jenkins，它作為CI管道的一部分運行同樣的檢查眷昆。
該團隊需要在不同的場景下對不同客戶的多個數(shù)據(jù)集進行測試他們的模型蜒秤。正如Tymoteusz Wolodzko在他的解釋博文中所承認的，這不是他們想要手動設置和運行的東西亚斋。
他們需要協(xié)調(diào)和自動化管道作媚，他們應該能夠很容易地插入到生產(chǎn)環(huán)境中。Docker化他們的ML代碼伞访，使他們可以很容易地在不同的環(huán)境中移動應用程序掂骏，這包括生產(chǎn)環(huán)境。
對于協(xié)調(diào)厚掷，該團隊從Airflow切換到Argo工作流弟灼，所以插入他們的容器只是寫幾行YAML代碼的問題。
Argo Workflows & Pipelines是一個開源的容器原生工作流引擎冒黑，用于協(xié)調(diào)Kubernetes上的并行作業(yè)田绑。它是一個為Kubernetes從頭設計的云原生解決方案。你可以定義管道工作流程抡爹，其中單個步驟是作為一個容器進行的掩驱。
Argo工作流程使該團隊能夠在他們的亞馬遜EKS集群上輕松運行機器學習或數(shù)據(jù)處理的計算密集型工作。管道中的模型會根據(jù)預定的作業(yè)定期重新訓練冬竟，也會進行必要的測試和檢查欧穴。但在模型部署之前，它們會被一個領域?qū)＜覍彶楹蛯徍吮门埂Ｒ坏＜掖_認該模型可以部署涮帘，模型就會被手動部署。
使用AWS CodePipeline和Step Functions的ML持續(xù)集成和交付（CI/CD）笑诅。
為了協(xié)調(diào)他們的CI/CD工作流程调缨，本節(jié)中的團隊使用了AWS CodePipeline和AWS Step Functions的組合，以確保他們正在構(gòu)建一個自動化的MLOps管道吆你。
感謝Phil Basford接受我的采訪弦叶，介紹他的團隊如何為一個公共ML用例做CI/CD。
對于這個用例妇多，團隊來自一家咨詢和專業(yè)服務公司伤哺，他們在一個公共項目上工作。具體來說砌梆，他們建立了機器學習應用默责，解決了以下問題贬循。
- 預測運送一個包裹需要多長時間咸包。
- 預測一個位置桃序，基于非結(jié)構(gòu)化的地址數(shù)據(jù)，并將其解析為一個坐標系（緯度/經(jīng)度）烂瘫。
核心CI/CD工具
- AWS CodeBuild - 一個完全管理的持續(xù)集成服務媒熊，可以編譯源代碼，運行測試坟比，并產(chǎn)生可以部署的軟件包芦鳍。
- AWS CodePipeline - 一個完全管理的持續(xù)交付服務，可以幫助你實現(xiàn)發(fā)布管道的自動化葛账。
- AWS Step Functions - 一個無服務器的功能協(xié)調(diào)器柠衅，可以輕松地對AWS Lambda功能和多個AWS服務進行排序。
AWS云提供了受管理的CI/CD工作流程工具籍琳，如AWS CodePipeline和AWS Step Functions菲宴，為其機器學習項目進行持續(xù)集成和持續(xù)交付。對于持續(xù)集成趋急，該團隊使用git向AWS CodeCommit提交喝峦，從而觸發(fā)CodePipeline中的構(gòu)建步驟（通過AWS CodeBuild作業(yè)），而AWS Step Functions處理來自CodePipeline的每個動作的工作流程協(xié)調(diào)呜达。
來自AWS Step Functions的工作流協(xié)調(diào)過程使該團隊能夠輕松管理因使用CodePipelines運行多個模型和管道而產(chǎn)生的復雜性谣蠢。團隊所做的多模型部署更容易管理和更新，因為CodePipeline中的每個管道工作都專注于一個流程查近，構(gòu)建也更容易交付和排除故障眉踱。
下面是一個項目的例子，該項目使用AWS CodePipeline以及Step Functions來協(xié)調(diào)需要自定義容器的ML管道霜威。在這里谈喳，CodePipeline調(diào)用Step Functions，并將容器圖像URI和獨特的容器圖像標簽作為參數(shù)傳遞給Step Functions侥祭。
使用AWS服務構(gòu)建CI/CD管線以部署自定義機器學習模型的架構(gòu)使用AWS服務構(gòu)建CI/CD管線以部署自定義機器學習模型的架構(gòu)
雖然這個團隊選擇使用這些工具來管理和協(xié)調(diào)叁执，但值得注意的是，對于持續(xù)集成和持續(xù)交付（CI/CD）管道矮冬，AWS發(fā)布了Amazon SageMaker Pipelines谈宛，這是一個易于使用、專門為ML設計的CI/CD服務胎署。
Pipelines是一個原生的工作流協(xié)調(diào)工具吆录，用于構(gòu)建ML管道，利用SageMaker的直接集成琼牧。你可以在這篇博文中了解更多關(guān)于使用 Amazon SageMaker Pipelines 構(gòu)建恢筝、自動化哀卫、管理和擴展 ML 工作流的信息。
使用Vertex AI和TFX在谷歌云上進行ML的持續(xù)集成和交付（CI/CD）
在本節(jié)中撬槽，我們將看看一個團隊在選擇和使用其工作流協(xié)調(diào)和管理工具時此改，能夠利用機器學習項目比傳統(tǒng)軟件工程項目更原生的管道。
本節(jié)將利用Hannes Hapke（Digits Financial, Inc.的ML工程師）在Google Cloud的Applied ML在線峰會期間舉辦的 "利用有限的DevOps資源進行快速迭代 "研討會侄柔。
Digits Financial, Inc.是一家金融科技公司共啃，為初創(chuàng)企業(yè)和小型企業(yè)提供可視化的、由機器學習驅(qū)動的費用監(jiān)控儀表板暂题。他們的用例集中在以下方面移剪。
為現(xiàn)代企業(yè)創(chuàng)建最強大的財務引擎，能夠攝取并將公司的財務信息轉(zhuǎn)化為實時的業(yè)務模型薪者。
- 從非結(jié)構(gòu)化文件中提取信息纵苛，為客戶預測未來事件。
- 對信息進行分類言津，以浮現(xiàn)出對客戶的業(yè)務最重要的內(nèi)容攻人。
Digits的團隊能夠通過管理Vertex AI Pipelines產(chǎn)品和TensorFlow Extended來協(xié)調(diào)和管理他們的機器學習管道的持續(xù)集成、交付和部署纺念，所有這些都在谷歌云基礎設施上運行贝椿。
與傳統(tǒng)的CI/CD工具相比，使用ML原生管道工具有助于團隊確保模型質(zhì)量的一致性陷谱，并確保模型在一個統(tǒng)一的管道中通過特征工程烙博、模型評分、模型分析烟逊、模型驗證和模型監(jiān)控等標準工作流程渣窜。
通過Tensorflow Extended，該團隊能夠?qū)⑵錂C器學習堆棧的每個組件視為單獨的步驟宪躯，當管道部署到測試環(huán)境或生產(chǎn)環(huán)境時乔宿，可以由第三方工具（如Apache Beam、Apache Airflow或Kubeflow Pipelines）進行協(xié)調(diào)访雪。他們還能夠創(chuàng)建自定義組件并將其添加到他們的管道中详瑞，這在使用傳統(tǒng)的CI/CD工具時是很難做到的。
與此同時臣缀，他們還將他們的ML管道從Kubeflow轉(zhuǎn)移到Google Cloud的Vertex AI Pipeline坝橡，幫助他們輕松地將模型開發(fā)（ML）和操作（Ops）結(jié)合起來，形成高性能和可重復的步驟精置。
該團隊提供的使用Vertex AI Pipelines的核心優(yōu)勢之一是计寇，它幫助他們從管理他們的管道（自我托管的Kubeflow管道）過渡到利用管理的Vertex AI Pipeline服務進行工作流程協(xié)調(diào)，從而擺脫了維護存儲元數(shù)據(jù)的數(shù)據(jù)庫、啟動集群以托管和操作構(gòu)建服務器和管道的需要番宁。
Vertex AI是一個可管理的ML平臺元莫，供每個從業(yè)者加快實驗速度，加速機器學習模型的部署蝶押。它通過以無服務器的方式協(xié)調(diào)他們的ML工作流程踱蠢，并使用頂點ML元數(shù)據(jù)存儲他們的工作流程的工件，幫助團隊實現(xiàn)自動化播聪，監(jiān)控和管理他們的ML系統(tǒng)朽基。
過將其ML工作流程的工件存儲在Vertex ML Metadata中布隔，他們可以分析其工作流程的工件的脈絡 - 例如离陶，ML模型的脈絡可能包括訓練數(shù)據(jù)、超參數(shù)和團隊用于創(chuàng)建模型的代碼衅檀。
該團隊的工作流程包括用TensorFlow Extended準備和執(zhí)行他們的機器學習管道招刨，并將它們運送到Vertex AI。然后哀军，他們可以從Vertex AI管道中管理和協(xié)調(diào)他們的管道沉眶，而不需要操作他們自己的集群。
該團隊能夠從使用ML管道來協(xié)調(diào)和管理他們的ML工作負載中受益杉适，有幾種方式谎倔。正如Hannes Hapke在這段視頻中所描述的，這家初創(chuàng)公司能夠獲得以下好處猿推。
- 使用ML管道減少了對團隊的DevOps要求片习。
- 遷移到管理的ML管道，減少了他們在基礎設施上托管管道時運行24/7集群的費用蹬叭。
- 由于ML管道是ML工作流程的本機藕咏，模型的更新很容易集成，并且是自動化的秽五，從而使團隊騰出時間專注于其他項目孽查。
- 模型更新在所有ML項目中都是一致的，因為團隊可以運行相同的測試并重復使用整個管道或管道的組成部分坦喘。
- 所有與機器學習相關(guān)的元數(shù)據(jù)和信息都有一個一站式的場所盲再。
- 模型現(xiàn)在可以自動被跟蹤和審計了。
可能是有用的
結(jié)論
本文揭示的一個有趣的觀點是瓣铣，使用CI/CD工具并不足以成功運營你的機器學習工作負載答朋。雖然本文中的大多數(shù)團隊仍然使用傳統(tǒng)的CI/CD工具，但我們開始看到ML原生管道工具的出現(xiàn)坯沪，可以幫助團隊（無論其規(guī)模如何）更快绿映、更可靠地交付更好的機器學習產(chǎn)品。
如果你和你的團隊正在考慮為你的機器學習工作負載采用CI/CD解決方案，任何一個ML原生管道工具都可能比傳統(tǒng)的基于軟件工程的CI/CD工具更值得開始使用叉弦，當然丐一，這取決于你的團隊的情況和有利的工具或供應商的合作。
