軟體工程的 DevOps 取向,透過統一開發與營運,徹底改變了發行速度。您的開發團隊現在很可能就是由 DevOps 原則提供強制持續整合與部署的架構,藉此引導開發團隊的流程。當您運用 DevOps 取向來開發軟體時,您即遵循開發、測試、驗收和生產 (DTAP) 所構成的生命週期。擁有大型開發團隊的組織,尤其是開發團隊散布各地的組織,已意識到需要採用 DevOps 取向來大幅改善其軟體開發生命週期 (SDLC) 流程。正因如此,採用相同的 DevOps 取向在全企業開發機器人流程自動化 (RPA) 機器人,再恰當不過。
現今,大多數 RPA 解決方案提供各種功能,讓您能將機器人從開發生命週期的某一階段移到下個階段。這是否表示,這些解決方案支援 DevOps 取向的機器人生命週期管理 (BLM)?其實不然。只要機器人遵照 DevOps 生命週期就構成 BLM,這樣的想法是一種迷思。但正如許多其他迷思,如果不深入檢驗,乍聽之下也能魚目混珠。
DevOps 與 BLM 並不相同
DevOps 生命週期的每個階段分別都在不同的環境中展開。在一個環境中進行開發,然後在另一個環境進行測試。生產則又是在另一個環境。因此,要管理機器人的生命週期,需要能依照機器人所在的生命週期階段,為機器人維持各自的環境,而且需要能讓整個機器人套件依次通過不同階段。
假設您建造了 A 機器人,為了讓機器人有效運作,A 機器人依賴個別流程 A.1、A.2 和 A.3。因此,需要管理機器人和其相依性,並且以同一套件的形式循序通過機器人生命週期。您說:「顯然是要這樣」。但是大多數 RPA 解決方案還沒辦法這麼做,他們只是將機器人匯入和匯出您所提供的環境。您要分開管理機器人相依性。您可能會問:「真的嗎?聽起來很麻煩。」真的。而且,沒錯,任何一位 RPA 程式管理員都會這樣回答您,這真的很麻煩。
如未設置真正的 BLM 架構,則必須建立和管理開發與測試環境。您也必須個別管理和推進相依性。當您只是在為 RPA 進行概念驗證時,這種做法或許行得通,但是卻無法擴充。必須用互不相連的流程來管理的機器人越多,就需要越長的時間,才能將機器人投入生產。此外,如果相依性不慎遺漏,可能會出現更多錯誤,延誤持續整合與部署。
合規也可能會是一個問題。對於有合規要求的機器人接觸流程,例如美國沙賓法案 (SOX) 涵蓋的財管流程,缺乏真正的 BLM 架構,會迫使您不得不開發和管理自家公司的機器人控管技術。
運用 BLM 進行擴充
BLM 架構包含在 Automation Anywhere Enterprise 內,不僅只匯入和匯出機器人,還能輕易地與 DevOps 工作流程整合。內建對個別開發、測試、驗收和生產環境的支援,包括完整版本控制與回復功能。
高度精密的角色型存取控制 (RBAC) 是企業必備的另一項功能,可強化企業 RPA 平台的安全性。有了精密的 RBAC 功能,機器人就能順利通過 DevOps 生命週期的各個階段。那要怎麼處理相依性?相依性會跟隨機器人通過整個生命週期。因為 Automation Anywhere Enterprise 會在機器人生命週期中管理整個機器人套件。即使有嚴格的合規要求,這項控制版本、角色和機器人套件的功能,仍然讓您能更快地開發更多機器人。這讓您能快速將 RPA 擴充到整個企業,並且更快地獲得更高的投資報酬率,這是精心研擬的企業級 RPA 策略的一大特點。
立即申請示範 Automation Anywhere Enterprise 平台,獲得第一手機器人生命週期管理體驗。