突破效能瓶頸,實現流程自動化

韓楠發表於2022-08-29


責編 | 韓楠

約 2355 字 | 5 分鐘閱讀


你好,今天我想跟你聊聊如何透過流程自動化驅動研發效能提升, 工業革命以來,自動化技術極大改變了人們的工作和生活 而軟體研發過程的自動化則 成了 新的挑戰

從上世紀八九十年開始,計算機輔助軟體工程和基於模型的軟體開發等方法逐漸興起,直到近十年的低程式碼軟體開發等,一直在致力於透過工具和技術的手段 來提升軟體的生產效率。

在如今這個“軟體正在吞噬世界”的時代,作為一名軟體工程師,需要實現的需求數量如滾雪球般逐漸增加,超時工作已經成為軟體從業者的常態,不過透過軟體研發流程自動化 可以實現個人和組織 的效能提升。 本文將從以下兩個維度 分別闡述下研發流程自動化的應用方法和收益:

•  單項任務的自動化

•  多工自動化協同




01   單項任務的自動化

很多企業都是先從自動化釋出和運維起步,然後逐步往前推進自動化

從下圖可以看到,這個研發生命週期的簡單模型中,按照時間線來看,一個需求從想法轉換為設計、落地到程式碼、再生成二進位制包、結合環境資訊釋出到生產,整個過程不確定性是從後往前逐 漸增加的。 軟體生命週期,不確定性變化

而不確定性則是實現自動化的一大挑戰,因此目前階段對於具備發散特性的程式碼開發過程自動化,雖然已經有很多優秀的學術研究成果和部分的落地實踐,但是仍然沒有在企業中實現大規模的落地和推廣。

按照以上思路,我帶你先從自動部署這個   最常被大家提起的自動化實踐展開探討。

▶︎   自動部署

微軟公司在2019年時,每天部署超過8萬次,如果每次部署都需要手動執行,可想而知是多麼痛苦的一件事情。

雖然一般在小型的軟體公司不會有這麼多的部署需求,但是對一名開發人員來說,部署仍然是需要每天面對的,具體來說比如測試環境的部署、準生產環境部署和生產環境部署。

到現在我還記得大概十年以前,當時還是透過指令碼部署測試環境時是多麼耗費時間,常常是一邊執行部署指令碼,一邊檢視啟動日誌

如果順利執行完成則會感到非常慶幸,接下來再去執行另外一個指令碼,甚至在執行指令碼前還需要修改一些部署目錄等引數變數,整個部署過程是不可重複的且不穩定的。

而到現在隨著雲原生技術的興起,軟體的部署過程已經完全實現自動化,從過程化指令碼、到指令碼與配置分離、然後再到Ansible和Puppte等此類自動化配置工具的應用。

如今在基於雲的環境下,無論是公有云還是私有云,IAC(基礎設施即程式碼)已經廣泛應用,自 動部署變得越來越穩定和快速,並且能做到完全的重複執行。

自動部署技術演進

部署流水線進一步增強了編排能力,並且加入了前置的自動化測試等,把多個原子的自動化任務組合起來形成一條流水線,GitOps是一個很好的實踐。

▶︎   部署流水線

部署流水線進一步增強了編排能力,並且加入了自動化測試和靜態程式碼分析等前置任務,把多個原子的自動化任務組合起來形成一條流水線。自動化流水線兩個重要的特性分別是觸發器和編排能力:

  • Webhook觸發器

拿Github程式碼倉庫舉例,當一個特性分支要合併到受控分支(Master)時,會發起Pull Request,為了確保受控分支的程式碼質量,一般會在此時進行CodeReview(程式碼評審)

而自動化的靜態程式碼分析 可以作為人工評審前置操作,提取過濾掉一 些低階別的程式碼錯誤,如空指標異常等。以下為由Pull Request的Webhook來觸發靜態程式碼分析的流程圖: pull request 觸發靜態程式碼掃描

  • 流水線編排

由Pull Request擴充套件開來,可以編排一個包含自動化測試的流水線,其中會包含測試環境部署的步驟。以下為流程圖: pull request 觸發完整部署流水線

談到支援流水線編排的工具,就不得不提起我們大家都熟悉的Jenkins,該工具至今仍然是被廣泛使用的流水線平臺之一。而隨著GitHubAction、GitLabCI和Argo CD等支援GitOps的工具流行起來,GitOps實踐逐漸成為一種趨勢。

圖源:Argo CD官網-Argo CD的架構圖

▶︎  自動 部署的應用

單獨的自動部署過程屬於單項任務的自動化,而部署流水線則需要多個自動子任務的協同,只不過這是一種簡單的串型執行的協作方式。在實際應用中,自動部署和部署流水線的應用場景卻略有不同。

單項任務的自動化,無論是自動構建、自動部署或自動化靜態程式碼分析,現在都被整合到IDE(整合開發環境)中了。這樣做帶來的好處是,作為一名軟體開發人員,不需要切換工具或平臺,就可以在本地的整合開發環境中實現這些操作,帶來個體效率的提升。下圖為阿里雲的自動部署外掛

圖源:阿里雲官網-Alibaba Cloud Toolkit部署外掛

部署流水線這種多工協同的自動化,仍然需要有個專門的工具或者平臺來支援,不過並不影響透過IDEA外掛來觸發執行。

未來可以實現本地外掛和雲端服務的結合,本地外掛負責觸發執行,並能夠展示結果 而云端服務則透過雲原生技術 來分散式地高效執行流水線。

本地外掛觸發流水線

▶︎  低程式碼平臺

目前業界對於低程式碼的看法 仍然存在一些爭議 有人認為低程式碼是未來軟體開發的大勢所驅,也有人對其持有負面的意見。

在這裡先拋開分歧,從實際應用情況來看,低程式碼平臺已經在企業軟體開發領域 逐步開始發揮作用了。 特斯拉公司曾經用低程式碼片平臺Mendix 快速實現自建ERP系統,各個IT巨頭也紛紛搭建自己的低程式碼平臺。

圖源:文章《Low-code development and model-driven

engineering: Two sides of the same coin》

有效使用低程式碼平臺,可以極大地提升效率。用免費的建站工具wordpress 最快可以十幾分鍾搭建一個網站出來。

OutSystems和Mendix這樣的低程式碼平臺 則可以支援更多型別的應用建立,包含網頁端、移動端和IOT應用等。透過與雲原生基礎設施的結合,整合了企業級DevOps工具,從建立一個應用到完成釋出實現了無縫銜接。下圖為OutSystems的介紹:

圖源:OutSystems官網文章《Developing with OutSystems》

低程式碼平臺提供的功能 除了我們常見的透過拖拽控制元件方式來生成前端應用外,還有基於DSL語言、流程圖和狀態機等方式 來直接生成應用程式。從模型到可執行的應用 通常有兩條實現路徑:

•  1)透過模型 來生成程式碼,生產的程式碼或位元組碼,直接執行在JVM這樣的執行時環境,成為可執行的應用。

•  2) 透過執行後設資料的方式,模型以後設資料的方式儲存,然後透過直譯器來直接執行後設資料,從而實現應用的功能。

第二種方式執行更加高效,因為其減少了生成程式碼的過程,使開發、部署和測試過程更加快速。在實際使用情況下,兩種方式可以分別單獨使用或者結合使用。


02   多工協同的自動化


在單點效率的提升方面,如自動部署、自動程式碼質量檢測和自動化測試等,目前已經有很多優秀的實踐,並且使單點效率得到了很大的提升。

不過縱觀整個軟體研發生命週期,僅僅提升單點的效率是不夠的,還需要透過提升多工的協同效率 來減少等待時間和提升整體的效率。

圖中示例可以看出有很多重協同的任務,其總交付時間(lead time)會比處理時間(processing time)要多,是因為這些任務有一些前置準備和等待的時間,因此就會使總交付時間變長。

比如一個任務從設計進入開發,需要一些評審和溝通的時間,從開發完到測試開始之前,又需要一些測試環境準備的時間。  

因此可以說,從單點自動化到流程自動化,是提升研發效能的一個必然發展路線。

透過流程自動化來提升多工協同效率的具體手段,可以從視覺化和自動化兩個方面入手:

  • 視覺化

主要指上下級或上下游任務之間資料的打通,如在需求維度可以檢視開發過程的程式碼相關資訊和測試維度的相關資訊,這樣的做法使不同視角均能夠準確且及時獲取更加完整的資訊,利於多角色高效協同。需求關聯開發和測試資訊如下圖:

需求任務與開發測試資料關聯

如上圖,以需求和任務為主線,關聯了開發過程中的資料包含程式碼提交資訊、程式碼合併請求和程式碼分支資訊,還有測試過程中的缺陷、用例和提測單資料。

  • 自動化

主要是指不同任務的前置和後置任務,能夠根據規則自動化觸發執行、多個任務之間的狀態自動同步等。下圖是使用GitHub時,透過git命令觸發issue的狀態變為關閉的實踐:

以下為透過Jira自動化規則來分配任務的實踐,可以根據提前設定好的規則,自動把任務分配給狀態為空閒的團隊成員。

總結起來,有以下幾種型別的流程自動化工程實踐:

▶︎  結語

作為一名軟體開發人員,我們的日常工作就是透過技術手段使業務流程自動化,從而提升業務運營的效率。而對軟體研發活動自身來說,目前還有很多低效的和手工的操作,可以說,研發效能提升正是要找到這些效能瓶頸 並透過技術手段來實現改變。

自動化技術正是解決低效工作的最佳手段,我本人也是從自動化測試開始入手,逐步到自動化部署、自動化程式碼檢測 到現在致力於透過工具來實現多工的自動化協同,深刻體會到了自動化帶來的收益。

關於軟體研發流程自動化的更多實踐和觀點,歡迎 留言區 和我一起探討。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70016482/viewspace-2912391/,如需轉載,請註明出處,否則將追究法律責任。

相關文章