用敏捷的DevOps拳打研發低效、腳踢管控不足
在為客戶進行DevOps諮詢和提供解決方案時,除了“又快又好”的釋出之外,我們發現客戶通常還有兩大方面需求: 開發測試管理問題和執行管理問題。以某大型金融企業為例,該企業開發測試問題主要表現為 研發過程的管控不足,這帶來了 開發效率低、版本質量差、環境交付慢等一系列問題。另外,整個 執行環境缺乏統一管理,資源申請和獲取週期長,資源利用率低也是當前執行管理中頻繁出現的問題。
問題1
研發過程無法清晰度量、檢視和分析
流程規範不標準,各專案各自為戰
缺少統一的研發管理支撐工具,已有的流程規範無法有效落實
解決方案
流程的平臺化、固化,自動驅動流程運轉
不同的公司有劃分階段不同,同一個公司也有可能會分為不同的階段。在整個流程體系下,每個角色、每個人要做什麼是DevOps落地非常重要的一個關鍵點。 透過平臺去把所有的規範固化,需要在流程的每個階段,把每個人的工作職責,需要遵守的規範,甚至是考核指標、度量資料都確認下來。這樣每個人能清晰的瞭解自己的職責,按圖索驥去完成自己的工作。
規範的落地是DevOps能夠正常運轉的一個重點。從立項到整個需求任務、開發測試、釋出上線的過程裡,大概50%能規範化並落地到平臺中,另外還有些工作例如會議需要人員管控。每個企業中可能有1-2套標準流程,不僅要匹配不同客戶的需求,和同一企業中不同專案的需求,還有隨著企業對DevOps認識的不斷提升,流程也會隨著認知不斷演進。流程的自定義和靈活性就顯得非常重要。
如何自動驅動流程也是一個關鍵。博云為該企業設計了自定義工作流引擎, 整個流程的固化,從前期的準備到後面的需求、研發、不同的測試階段,都可以透過devops平臺上企業自定義的研發工作流來驅動。它不僅能展現當前標準流程的進度,同時企業能夠用標準流程去驅動底層的工具鏈與整個研發管理過程。不管從需求、評審或是運維等角度,整個底層、研發流程的狀態變化能夠驅動流程和工作引擎的狀態變化。例如從需求待開發進入開發階段後,整個版本也從待規劃階段自動變化到開發階段。
問題2
開發測試環境搭建交付慢,耗時長
同一業務系統跨多平臺部署,效率低,耗時長,管理複雜
物理機、虛擬機器、容器各自管理,沒有統一檢視
解決方案
多視角的環境管理
環境管理既重要又很困難。首先底層環境有很多種,可能需要與虛機環境,跟雲平臺、雲管平臺對接,還有容器化環境等不同的環境。其次,環境管理有時候是有專案視角的,有時候為這個專案分配了多少環境,同時專案裡還有應用、服務、系統等概念,專案中可能有三套系統,並給這三套系統分配了不同的環境。還有一種是按最小粒度去分配,例如有5個服務,每個服務有不同的環境。這幾個情況都有可能會出現。 從環境角度來看,應用服務是個核心視角,也有專案視角,所以我們為客戶設計了樹狀結構的多視角環境管理支援。這個樹狀結構有專案—應用—服務三級視角。
現在的研發管理流程中,包含非常多的物件。從專案視角來看,它注重的是開發階段,需求任務缺陷和非常重要的研發管理的項。從程式碼提交開始,它的管理物件是應用和服務,比如程式碼是和哪個服務關聯,製品是和哪個服務關聯,pipeline和部署也是與應用服務關聯。 也就是說專案/版本,應用/服務是我們兩個核心的管理物件,那如何才能實現相容這兩種方式?
我們在實踐中發現,以應用服務視角去統一或以專案視角去統一這兩點都是需要的。在程式碼之前需要的是專案視角,在程式碼之後最核心的是應用服務視角。 透過應用服務去關聯程式碼、環境、pipeline、製品,這是最自然的也是最好用的一套邏輯。還有一個就是人員,除了角色物件這些東西外,它核心也會體現在所有績效、工作量和團隊。
環境管理的落地流程從整個環境規劃開始。在流程的前端,一開始就給專案申請環境與配額,最後環境細化的分配到各個專案和應用中去。然後透過pipeline的自動化把環境部署起來,由環境申請到環境釋放這樣一個過程,底層與各種各樣的資源平臺去對接。
整個資源環境管理的設計能夠相容各種各樣的需求。應用本身是可能有很多環境的,我們實現了一個應用能隨時建立一套自己可用的環境,在整個資源平臺與不同的容器平臺、虛機環境、雲管平臺上建立的專案相匹配,並進行多個關聯。
問題3
缺乏開發測試釋出環境的質量管控
缺乏開發規範或者規範難落地,程式碼質量差
編譯打包部署自動化程度低,效率低,易出錯
解決方案
以版本為核心的過程管理和追溯
以版本為核心的過程管理和追溯,我們理解是整個DevOps管理設計或是研發管理過程的核心的需求。從需求開始,程式碼、製品、包括線上的例項,都是能與版本進行關聯。但一直以來,很多企業的研發管理過程是做不到這點的。
我們透過DevOps平臺的整體自動化驅動,以版本為核心,從整個的從需求到程式碼、製品、構建、部署和例項的管理過程給支撐起來,將它與關聯項進行匹配,使資訊實現同步。這樣能實現線上執行的版本對應它的需求,能夠清晰的瞭解製品關聯哪些需求和版本。 這 樣能夠 解決整個線上版本和線下版本或不同測試環境裡的版本不一致的問題。
這裡關鍵的核心點是研發提測過程。整個研發過程中,研發提測把需求圈出來告訴測試,圈完之後就會走自己的pipeline,pipeline最後生成製品,這樣就實現了製品與需求的關聯。平臺還有提測單,提測單中不僅有製品和需求的資訊,還會有質量檢查的資訊。 這個資訊會一直跟著流轉到整個的版本測試報告中,也就是說我們不但知道這次測試的報告,還能知道所有中間過程中安全檢查和自動化測試的結果,是清晰可見的,這是一個關聯和資訊匹配的過程。
另外一個就是以版本為橋樑打通開發測試和生產環境。在開發測試和生產的過渡過程中,版本包含提測單、需求,也包含製品、配置、指令碼這些所有的資訊,這樣從開發測試轉化生產時,不僅是把製品轉過去,也包含了整個配置和指令碼資訊,這樣不僅能 實現製品包移植,它的配置資訊、指令碼資訊與開發測試環境也是一致的。
問題4
企業或專案個性化的問題和需求如何滿足
解決方案
強大的配置能力,適應當前與未來
不管是驅動團隊運轉的自定義工作流,還是自定義的度量指標等功能,DevOps平臺都能夠隨著客戶內部團隊的演進適應當前的需求還有未來的變化。另外,前臺的自定義DevOps門戶能夠把整個DevOps流程驅動起來並視覺化展現出來。
對開發人員來講,接收到的需求能在介面上看到,做程式碼也能在同一個介面上看到,製品、部署釋出上線,需要處理的流程的工作,都能在門戶中心看到。這樣就不需要用許多工具和每天登入十多個系統,就按看到的流程走。
整個工具的驅動也是一個重點與難點。工具較多,每個客戶使用的工具也不一樣。不管是對接還是納管,透過工具鏈和門戶的能力,把各種不同的工具驅動和管理起來,為開發人員和管理人員帶來價值。
問題5
平臺可用性差
解決方案
靈活與可用
目前市場上開源的或一些工具最大的特點就是能力很強,不管是外掛化還是配置化,能力很強但是可用性比較差。所以在這個方面,我們花了巨大精力考慮如何實現產品可用性和靈活性的平衡,讓可用性強但又很靈活,適應客戶的不同需求及特性。
整個DevOps實施落地包含三個關鍵因素——人、流程、工具,博雲從團隊協作,流程再造和工具整合三個方面,幫助某金融企業實現了業務驅動型團隊和標準化規範的敏捷流程,形成持續完善能力。由點及面,迴圈迭代完成研發測試運維的持續交付轉型,打造能夠真正落地的DevOps研發運維體系。
將原有的團隊轉變為以產品組和能力組共同組成的業務驅動型團隊;
落實敏捷支撐的標準化規範,簡化流程從而實現快速迭代;
打通應用全生命週期工具整合,形成DevOps的工具鏈。
透過一套敏捷作業管理框架,一組IT工具鏈和一個能展示所有環節和過程的視覺化平臺,博雲幫助企業實現面向需求-開發-測試-上線等全流程的端到端自動化流水線,驅動整個研發測試管理流程運轉,提高企業內部IT資產能力和開發質量管控水平,從而解決開發測試及執行管理中的種種問題,最終使得研發運維團隊業務支撐水平能力得到提升。
隨著企業數字化轉型的加速推進,DevOps將持續發展,BoCloud博雲將繼續探索使用者真實需求,提升產品能力,為使用者提供更加靈活、可用性更強的DevOps平臺,幫助企業真正建立DevOps文化,推進業務部門與開發團隊深度配合,提升研發運維效能,專注創造價值。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69923336/viewspace-2695031/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 拳打冥王腳踢地府——《Hades》戰鬥設計分析
- 史上最強 AI 翻譯誕生了!拳打穀歌,腳踢 DeepLAI
- 【敏捷研發系列】前端DevOps流水線實踐敏捷前端dev
- DevOps|研發提效-敏捷開發之每日站立會dev敏捷
- 費用管控定製開發
- DevOps與敏捷異同 - DZone DevOpsdev敏捷
- 從敏捷開發到DevOps,殊途亦同歸敏捷dev
- 使用Redis——拳打南山敬老院,腳踩北斗幼兒園Redis
- 油氣行業敏捷研發行業敏捷
- 研發流程在敏捷開發中的詳解敏捷
- 一款可以連結DevOps的敏捷開發工具dev敏捷
- 「產品經理全連線系列2」企業如何開展敏捷或DevOps的研發變革敏捷dev
- 勵志!海外開發者講述用腳做遊戲的研發經歷遊戲
- DevOps|研發效能價值如何衡量dev
- 使用DevOps強化敏捷(上)dev敏捷
- FPGA CFGBVS 管腳接法FPGA
- 三一集團數字化轉型探祕:以DevOps平臺構建敏捷研發體系dev敏捷
- 敏捷與 DevOps:是敵是友?敏捷dev
- 敏捷和DevOps:是敵是友?敏捷dev
- 敏捷DevOps是反康威定律? - rna敏捷dev
- 研發效能負責人/研發效能1號位 |DevOps負責人dev
- AI DevOps | ChatGPT 與研發效能、效率提升(中)AIdevChatGPT
- DevOps|研發效能解決的是企業效率問題dev
- DevOps落地實踐,BAT系列,敏捷看板devBAT敏捷
- 軟體開發流變史:從瀑布開發到敏捷開發再到DevOps敏捷dev
- 我們自研的那些Devops工具dev
- 功能設計:專案費用管控
- 碎碎念軟體研發02:敏捷之Scrum敏捷Scrum
- devops|中小公司不要做研發效能度量dev
- 加速企業構建敏捷IT,博雲DevOps平臺最新發布敏捷dev
- 交通管控
- Devops與敏捷二者能否結合?dev敏捷
- 管控風險的方法
- 工業園區能源管控系統開發,軟硬體整合管控平臺
- 拒絕“散漫”與低效 遊戲研發也需要一套設計規範遊戲
- 再聊我們自研的那些Devops工具dev
- Category 特性在 iOS 元件化中的應用與管控GoiOS元件化
- DevOps|研發效能不是老闆工程,是開發者服務dev