[[422465]]

【51CTO.com快譯】人們需要了解DevOps和低代碼方法面臨的挑戰(zhàn)和具有的優(yōu)勢，并著眼于為企業(yè)提供更有效的解決方案。

在當今數(shù)字優(yōu)先的世界中，企業(yè)對熟練的開發(fā)人員和IT專業(yè)人員的需求越來越高。根據(jù)Korn Ferry公司最近進行的一項調查，到2030年，由于缺乏熟練勞動力，全球可能會有超過8500萬個工作崗位空缺。

有人提出了一個有趣的問題：低代碼技術可以用來代替IT技術人才嗎?如果可以代替人工編程，那為什么不使用基于GUI的平臺來消除學習代碼的必要呢?

從歷史上看，“低代碼解決方案”主要用于描述技術平臺，這些技術平臺使非技術用途能夠在不知道如何編碼的情況下創(chuàng)建新的應用程序。通過這種方式，低代碼比DevOps相比更加接近敏捷理論的核心。低代碼致力于通過應用程序加速交付業(yè)務價值，而DevOps的重點是應用程序構建之后的交付和維護。

如果非IT人員使用低代碼應用程序開發(fā)平臺，那么IT專業(yè)人員如何在DevOps中使用低代碼解決方案?

對于許多核心的DevOps實踐者來說，低代碼的概念是DevOps的一種反模式。DevOps可能始于開發(fā)和運營團隊合作方式的一種文化演變，但如今它已經演變成自動化管道和集成工具鏈的世界。

代碼作為一種通用語言，使DevOps團隊能夠使用相同的工具和實踐來交付和維護大量的應用程序和技術。DevOps團隊使用代碼，為負責交付和維護基礎設施和應用程序的運營團隊帶來了與構建應用程序的開發(fā)團隊相同的敏捷性水平。

要了解DevOps團隊如何使用低代碼解決方案，需要擴展思維，了解如何將低代碼的原則應用于“基于代碼”的解決方案，使其更易于學習、使用和維護。通過這樣做，可以提出三種類型的低代碼解決方案：

(1)低代碼應用開發(fā)平臺

(2)機器人流程自動化(RPA)平臺

(3)低代碼開發(fā)語言

以下了解當今DevOps中最流行的三種不同類型的低代碼解決方案，以及每種解決方案的優(yōu)缺點。

1.低代碼應用程序開發(fā)平臺

低代碼應用程序開發(fā)平臺如今已成為涵蓋了全面行業(yè)分析師的標準技術集。Gartner公司為企業(yè)低代碼應用程序平臺發(fā)布了Gartner魔力象限，并預測2021年的增長率為23%。當今市場上采用最多的低代碼平臺之一可能是Salesforce Lightning Platform Mobile。

低代碼應用程序開發(fā)平臺不僅有助于解決開發(fā)人員的技能差距，而且使業(yè)務專家能夠設計和構建滿足其確切需求的系統(tǒng)，同時繞過使用IT定義需求并確定項目優(yōu)先級的繁瑣過程。一篇標題為“Salesforce移動應用程序開發(fā)的未來”博客文章引用了一個與Salesforce平臺相關的示例，例如荷蘭連鎖超市集團Jumbo公司采用Salesforce平臺，能夠在8周的時間內構建內部協(xié)作和任務管理系統(tǒng)、客戶營養(yǎng)應用程序和當天送貨訂單系統(tǒng)。

(1)優(yōu)點

該領域解決方案的主要優(yōu)點與易用性有關。非開發(fā)人員只需點擊鍵盤和鼠標，就可以創(chuàng)建簡單的應用程序、配置用戶界面(UI)并部署到應用商店。低代碼工具不需要或只需要更少的培訓，可以使企業(yè)的業(yè)務更加敏捷，并對不斷變化的市場動態(tài)做出更快的反應，從而提高競爭力。

(2)缺點

低代碼應用程序開發(fā)平臺通常采用瀑布式開發(fā)模式。一旦應用程序被創(chuàng)建以滿足特定需求并交付，就沒有了繼續(xù)開發(fā)或增強的計劃。其定制能力、靈活性和集成選項是有限的，并且也可能出現(xiàn)安全問題。

通常情況下，復雜的應用程序或具有高度安全問題的應用程序并不是很好的選擇。如果不在企業(yè)級別進行管理，應用程序的長期所有權也可能是一個問題，并導致“應用程序蔓延”。

2.機器人流程自動化(RPA)平臺

機器人流程自動化(RPA)程序通過使用記錄器創(chuàng)建軟件腳本，使企業(yè)能夠使用重復的任務實現(xiàn)自動化。對于那些在Microsoft Excel中使用宏記錄器的人員來說，這是一個類似的概念。

創(chuàng)建腳本之后，用戶可以使用可視化編輯器修改、重新排序和編輯其步驟。UiPath公司在2021年4月21日首次公開募股(IPO)，標志著這些解決方案的日益普及，最終成為歷史上規(guī)模最大的軟件IOP事件之一。

RPA程序的用例是無限的——任何通過用戶界面(UI)完成的重復任務都是候選任務。在RPA領域中，人們已經看到業(yè)務用戶設計的應用程序(UiPath和Blue Prism)與更傳統(tǒng)的DevOps工具(特別是在測試自動化領域，例如Tricentis、Worksoft和Egglplant)以及新的基于對話的解決方案(如Krista)的交叉點。

在測試實現(xiàn)自動化的情況下，向用戶提供輕量級記錄器，他們可以記錄業(yè)務流程。然后將記錄反饋給自動化團隊，自動化團隊創(chuàng)建一個強化的測試用例，然后將其輸入持續(xù)集成(CI)/持續(xù)交付(CD)系統(tǒng)。這消除了獲取準確文檔以構建測試用例的挑戰(zhàn)，并使LOB訂單能夠確保將其最關鍵的業(yè)務流程作為任何變更的一部分進行測試。

像Krista這樣的解決方案將在DevOps工具鏈中使用。人們需要考慮一個非常熟悉的問題，“將在哪里發(fā)布?”而使用Krista，可以向系統(tǒng)發(fā)送問題，Krista將通過結構化對話檢索信息，以找出發(fā)布的位置并回復。

(1)優(yōu)點

使用戶只需記錄他們的日常活動即可快速輕松地創(chuàng)建自動化。重復的任務可以輕松地實現(xiàn)自動化，并且可以消除相關的用戶錯誤。RPA也非常適用于“一次性”項目，而在這些項目中，投資開發(fā)人員和資源沒有意義。

(2)缺點

RPA構建的工作流程可以作為可能無法擴展的長期系統(tǒng)更改和更新的補充。此外，自動化長期維護的所有權可能會隨著安全性和合規(guī)性要求而變得不明確。

3.低代碼開發(fā)語言：編碼命令

基于低代碼開發(fā)語言的工具包括許多著名的DevOps工具，其中包括Ansible、Chef、Hashi、Puppet、Jenkins等。低代碼開發(fā)語言符合這樣一種基本信念，即“編碼方法”并不意味著每個人都必須成為編碼人員。

正如基于GUI的解決方案帶有用于執(zhí)行各種命令的“用戶友好”按鈕一樣，這一類別中基于代碼的解決方案帶有預構建的命令、幫助程序和資源。

例如，Chef語言包括一組強大的技術無關命令，為配置、測試和驗證系統(tǒng)提供強大的自動化功能。無論使用何種技術，其命令都保持不變。而使用這些命令，用戶只需很少的代碼知識就可以在大量設備上執(zhí)行復雜的功能。

除了使用人類可讀的語言、易于編輯的預填充自動化模板，以及與其他DevOps工具的一組強大的預構建集成之外，該領域的提供商還開始提供可視化儀表板和用戶界面(UI)驅動的更多功能，以實現(xiàn)功能的監(jiān)控部署并確保系統(tǒng)安全。Chef Infra Client 17就是一個很好的例子，其中向Chef Automate添加了新的基礎設施管理儀表板和用戶界面(UI)驅動的功能。

這種混合方法通過為用戶提供易于學習的基于代碼的平臺，可以輕松與持續(xù)集成(CI)/持續(xù)交付(CD)系統(tǒng)集成，并為非技術用戶和管理人員提供整個組織的可見性和分析，從而實現(xiàn)兩全​​其美。

(1)優(yōu)點

低代碼開發(fā)語言提供更大的靈活性和可擴展性。由于它們基于Ruby、Python或Yaml等底層語言，因此可以輕松擴展和定制它們以處理最復雜的自動化場景。這些工具也是大型成熟生態(tài)系統(tǒng)的一部分，通常由社區(qū)驅動，因此有1,000多個預構建的內容模板和集成插件，可以輕松構建自動化并集成到持續(xù)集成(CI)/持續(xù)交付(CD)管道中。

(2)缺點

低代碼開發(fā)語言仍然基于腳本，需要使用者對開發(fā)實踐有基本的了解。其工具需要升級和維護，即使是自動化的工具也是如此。由于它們專為解決IT管理特定挑戰(zhàn)而構建，因此它們不太適合非IT技術用戶。

超自動化將成為低代碼DevOps平臺的下一個重要驅動力

由于受到新冠疫情的影響，企業(yè)對于提高數(shù)字運營效率的需求越來越強烈，他們需要在任何地方為客戶和員工提供支持和服務。

滿足數(shù)字優(yōu)先世界日益增長的需求的唯一途徑是實現(xiàn)自動化，這種自動化不僅需要易于創(chuàng)建，而且易于維護和擴展。DevOps領域的自動化提供商將繼續(xù)向低代碼解決方案邁進，使企業(yè)能夠實現(xiàn)超自動化。也就是說，盡可能地將所有事情實現(xiàn)自動化。

原文標題：DevOps, Low-Code and RPA: Pros and Cons，作者：Heather Peyton

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】