速度和質(zhì)量不可兼得,為什么DevOps落地如此困難?
據(jù) Veritis 發(fā)布的《2019 年 DevOps 狀況報(bào)告》顯示,正確實(shí)施 DevOps 的組織有著明顯的競爭優(yōu)勢:軟件部署頻率提高 208 倍,事件恢復(fù)速度提高 2604 倍,變更失敗率降低 7 倍。這項(xiàng)結(jié)果讓更多企業(yè)看到了DevOps的高效之處,同時也使得 DevOps 在近年來慢慢有成為主流的趨勢。
近期,Techstrong Research 和 Testlio 對1000 多名工程師和 DevOps 專業(yè)人士進(jìn)行了調(diào)查,以了解他們對人才短缺、自動化和左移的看法。調(diào)查結(jié)果發(fā)現(xiàn),大部分企業(yè)都面臨人才短缺的問題,同時,很多團(tuán)隊(duì)為了提高軟件交付速度,而不得不犧牲軟件質(zhì)量。
以下是調(diào)查結(jié)果中的幾組數(shù)據(jù):
80% 的企業(yè)缺少 QE 人才
在軟件開發(fā)過程中,質(zhì)量工程師(Quality Engineer,QE)是一個關(guān)鍵的崗位,其主要工作是把一些手動、可重復(fù)的任務(wù)自動化,使流程更高效且不易出錯。Techstrong Research 的數(shù)據(jù)顯示,僅有 12% 的團(tuán)隊(duì)擁有合適的 QE 人才,超過 80% 找不到 QE 來支持測試和自動化,其中有大量團(tuán)隊(duì)沒有足夠的人才招聘預(yù)算。
事實(shí)上,不僅僅是 QE面臨人才短缺,而是所有 DevOps 技能職位都面臨人才短缺。Gartner 曾預(yù)測,由于人才的短缺,到 2022 年75% 的 DevOps 計(jì)劃將無法達(dá)到預(yù)期。
81% 的企業(yè)無法實(shí)現(xiàn)全自動化測試
測試自動化是測試團(tuán)隊(duì)的關(guān)鍵能力之一,調(diào)查發(fā)現(xiàn),已經(jīng)有過半的團(tuán)隊(duì)利用自動化來進(jìn)行測試,但其中僅有 19% 的團(tuán)隊(duì)能夠?qū)崿F(xiàn)全自動化測試,12% 的企業(yè)仍然采用手動測試,還有26% 的受訪者表示希望能夠在測試中利用自動化。
在各種類型的測試中,自動化的最佳用途是回歸測試。自動化回歸測試可以節(jié)省測試人員的時間,讓他們可以有更多時間專注于新功能的探索性測試。如果實(shí)施得當(dāng),自動檢查可以在最少或沒有監(jiān)督以及人工干預(yù)最少的情況下自動運(yùn)行。
不過,當(dāng)擁有了自動化測試工具時,也要警惕一種觀念:自動化所有的測試,是為了擺脫所有“手動測試人員”。
54% 的企業(yè)無法滿足用戶需求
還有一個值得關(guān)注的調(diào)查是,用戶對新軟件的特性、功能和更新的持續(xù)需求,增加了企業(yè)快速交付的壓力。54% 的受訪者表示,無法滿足用戶對開發(fā)新軟件和更新軟件的需求。
而那些聲稱“能做到”的公司,通常會犧牲質(zhì)量以換取速度。比如,為了節(jié)省時間,在發(fā)布前進(jìn)行不完整或表面測試,這樣開發(fā)出來的軟件,雖然可以跟著發(fā)布計(jì)劃走,但并不能達(dá)到消費(fèi)者對軟件質(zhì)量的預(yù)期。隨著時間推移,這些質(zhì)量問題最終會暴露出來,從而造成用戶不信任甚至用戶流失。
為了平衡速度和質(zhì)量,Testlio 合作伙伴生態(tài)系統(tǒng)副總裁 Emeka Obianwu 建議避免零和游戲??焖俚烷_發(fā)高質(zhì)量的軟件不需要相互阻礙。在高度優(yōu)化的軟件開發(fā)周期中,開發(fā)速度和軟件質(zhì)量應(yīng)該共同發(fā)展。
79% 的企業(yè)在CI/CD 管道集成測試
由于項(xiàng)目團(tuán)隊(duì)在交付無缺陷產(chǎn)品方面承受著巨大壓力,許多人正在采用左移方法、持續(xù)測試策略和嚴(yán)格封閉的反饋循環(huán),以便將測試集成到 CI/CD 管道的每個部分。Techstrong Research 調(diào)查顯示,將測試集成到 CI/CD 管道的企業(yè)達(dá)到了79% ,不過他們大部分都處于淺層次實(shí)踐之中。
應(yīng)用程序測試在平衡速度和質(zhì)量方面扮演著至關(guān)重要的角色,為了跟上對速度的需求和持續(xù)的技能短缺,將自動化和測試集成到 DevOps 流程中至關(guān)重要。
58% 的企業(yè)認(rèn)為“左移”意味著實(shí)現(xiàn)持續(xù)測試
“左移”這一口號在 DevOps 市場上已經(jīng)討論了好幾年,并且正在擴(kuò)展到業(yè)務(wù)的其他部分。但是,當(dāng)涉及到測試時,“左移”意味著什么呢?Techstrong Research 發(fā)現(xiàn),58% 的企業(yè)認(rèn)為“左移”意味著實(shí)現(xiàn)持續(xù)測試。這表明,整個行業(yè)發(fā)生了巨大的變化,在過去幾年中,“左移”就是將測試負(fù)擔(dān)轉(zhuǎn)移到開發(fā)人員身上的代名詞。
在軟件開發(fā)生命周期 (SDLC) 中,檢測和修復(fù)軟件缺陷的成本隨時間呈指數(shù)增長。越在開發(fā)過程的早期測試修復(fù)問題,左移測試對成本的降低越顯著。它通過使代碼與早期測試用例保持一致來減少初始開發(fā)階段的錯誤,缺陷在剛發(fā)現(xiàn)時就被修復(fù),而不是在最終的測試周期之后進(jìn)行修復(fù),以此節(jié)省維修成本和寶貴的開發(fā)時間。
一個典型的測試周期是 DevOps 團(tuán)隊(duì)交付代碼,測試人員運(yùn)行測試然后發(fā)回問題,然后循環(huán)重復(fù),而左移則可以消除開發(fā)和測試之間的冗長來回。 接受左移并避開標(biāo)準(zhǔn)的兩周黑盒測試周期,使測試成為 CI/CD 管道中的支柱,團(tuán)隊(duì)能夠滿足覆蓋率、質(zhì)量和速度要求。
Techstrong Research調(diào)查結(jié)果所暴露出的人才短缺、測試自動化程度不高、犧牲質(zhì)量換速度等問題,并不是突然出現(xiàn)的,而是一直以來就存在的。
有許多關(guān)注DevOps的企業(yè)一直在尋求解決之法,通過利用工具來完善流程成為業(yè)界共識。因此有許多DevOps工具應(yīng)運(yùn)而生,如提供 bug 跟蹤和敏捷項(xiàng)目管理功能的問題跟蹤器JIRA、自動化構(gòu)建Java項(xiàng)目的Maven等,但市面上的大部分工具能解決的都只是一部分問題,不能從根本上掃除企業(yè)在DevOps進(jìn)程中的障礙。
如何從根本上掃除DevOps實(shí)踐過程中的障礙,成了大家急需解決的痛點(diǎn),也正是看到這一點(diǎn),飛算云智總裁陳定瑋在六年前就開始了飛算 SoFlu 軟件機(jī)器人的研發(fā)。他說,DevOps 的實(shí)施對人才的依賴性強(qiáng),且對人員的基本素質(zhì)要求非常高,這也是很多 IT 公司在實(shí)踐 DevOps 時不得不以失敗告終的原因。
以上文提到的測試問題為例,飛算 SoFlu 軟件機(jī)器人的全自動測試平臺能夠優(yōu)化DevOps在企業(yè)中的實(shí)施,它能夠以自動化的方式,實(shí)現(xiàn)測試生命周期管理、測試用例自動生成、測試數(shù)據(jù)管理、精準(zhǔn)回歸測試等一系列功能,不僅降低了測試門檻,讓初學(xué)者輕松上手,還可以減少測試對資源的占用,提高執(zhí)行效率。
此外,飛算SoFlu軟件機(jī)器人還采用了通用的技術(shù)功能模塊,支持循環(huán)、條件判斷、函數(shù)調(diào)用等組件,用戶只要根據(jù)業(yè)務(wù)邏輯,通過拖拽方式進(jìn)行參數(shù)配置,就能完成編程。而且,平臺統(tǒng)一了代碼規(guī)范,不依賴人工編碼、審碼,因此可以從源頭上保證代碼高質(zhì)量??偠灾? 飛算SoFlu 軟件機(jī)器人通過可視化編程的方式滿足低門檻開發(fā)需求,輸入流程圖即可實(shí)現(xiàn)自動開發(fā)。
飛算 SoFlu軟件機(jī)器人能解決的不只是開發(fā)問題。事實(shí)上,在軟件項(xiàng)目開發(fā)過程中,風(fēng)險(xiǎn)幾乎無處不在。項(xiàng)目進(jìn)度是否正常、軟件質(zhì)量是否嚴(yán)格把控、技術(shù)是否成熟、系統(tǒng)架構(gòu)是否符合性能指標(biāo)等問題,都會威脅到軟件的最終交付結(jié)果。有效地識別、控制和管理風(fēng)險(xiǎn),對項(xiàng)目的成功起著至關(guān)重要的作用。
而通過飛算 SoFlu軟件機(jī)器人,一人就能完成開發(fā)、測試一整套流程,不僅提高了開發(fā)和測試效率,保證了代碼質(zhì)量,還使軟件工程全流程擺脫對人力的依賴,解決了人才不足的問題。用飛算SoFlu軟件機(jī)器人進(jìn)行開發(fā),可以真正實(shí)現(xiàn)“一人一項(xiàng)目,十人抵百人”。