在數字化浪潮席捲之下,不少傳統行業的線上業務急速增加,其業務場景、用戶行爲都發生了轉變,面對敏捷的業務和IT應變需求,如何快速地進行創新實驗,提升IT部門的整體運營效率,高效融合開發和運維的能力等一系列問題,已成爲企業須要直面的挑戰。前端
2009年以來,DevOps愈來愈被重視,最開始是爲了讓開發和運維人員更好地溝通協做,後來逐漸成爲打通軟件產品交付過程當中IT工具鏈和高效解決團隊成員協做溝通問題的有效理念。但DevOps的總體發展是獨木不成林的,如今已經有愈來愈多的技術支撐,微服務架構理念、容器技術等使得DevOps的實施變得更加容易。git
咱們研發團隊從內部產品研發需求出發,將敏捷管理、CI/CD、自動化測試、運營管理、基於SpringCloud的微服務架構、容器編排等相關開源工具整合爲一個PaaS平臺,用來支持這些傳統企業的數字化轉型。github
本文主要分析了項目研發團隊在開發過程當中存在的一些問題,介紹了Choerodon豬齒魚對此的解決方法,最後解答了應用遷移到Choerodon豬齒魚平臺前的幾點疑慮。數據庫
主要分爲如下幾個部分:編程
1、爲何要使用Choerodon豬齒魚後端
2、使用Choerodon豬齒魚以前的疑問安全
3、總結服務器
在Choerodon開發團隊接觸的大部分傳統企業中,他們面臨着業務創新的需求和壓力,同時也面臨着沒法很好得使用新型技術和方法快速將創意轉化爲產品的困境,IT團隊但願可以利用Agile/DevOps、微服務和容器技術幫助業務進行快速創新,相關的開源工具很是多,並且工具鏈條很長,把它們整合應用起來對IT部門來講要求很是高,不少傳統的企業並不具有這樣的能力。微信
▌應對易變的需求能力弱架構
傳統的研發項目每每採用瀑布式的開發方式,從立項、需求、設計、開發,測試到最終運營管理,因爲市場或者用戶的需求常常性發生變化,瀑布式模型的能力比較弱;固然,如今不少項目並非徹底遵循瀑布式的開發方式,在進入運營期當需求變化時,會進行靈活地處理,尤爲是持續更新的產品。但這種狀況仍缺少明確的管理策略,更多的是「東補西湊」的「理念」,與敏捷開發仍是有所不一樣。另外,開發人員每每沒有書面記錄用戶的變動需求,可能會致使沒法追溯系統軟件變動的歷史。
▌缺少有效的分支管理與版本控制機制
如今愈來愈多的項目使用Git做爲版本控制的工具,經過Git進行分支和Tag管理,大多數狀況這個過程都由手工完成,缺少相應的規範,對於分支和版本號的控制也很隨意,出現這樣的狀況每每是你們對軟件交付過程當中的軟件版本控制不夠重視,「只要確保軟件是最新的版本便可」,甚至是項目管理的漏洞或者缺陷。
▌多采用手工或者半自動的部署方式
可否實現自動化和高效地部署是衡量一個團隊工做能力的核心標誌之一。不少團隊採用手工的部署方式,有經驗的「老司機」都知道,部署過程每每都是拉取源代碼、編譯、構建,而後上傳到服務器、中止服務器、覆蓋代碼,最後啓動,甚至還有各類系統設置等。每次部署都要經歷這個過程,小到一個Bug的修復,大到發佈一個大版本。這樣直接會致使部署頻率較低,進而下降用戶需求或者價值的交付頻率。
▌文檔缺少規範管理
文檔是項目或者系統的積累和沉澱,包括項目初期的應用藍圖、架構圖、分階段實施計劃,以及開發過程當中的設計文檔、產品功能文檔等。在系統開發前期,你們可能對於維護文檔仍是比較積極的,可是隨着產品不斷迭代,慢慢你們就會疏於更新文檔,致使文檔與功能沒有辦法銜接對照。
▌缺少駕馭微服務架構的能力
近幾年微服務方興未艾,尤爲是Spring Cloud架構的不斷成熟,以及Service Mesh的正式版本發佈。因爲微服務架構體系涉及到的技術種類很是多,幾乎全部的微服務框架不能直接拿來使用,須要投入很大的人力物力進行前期研究、基礎系統框架的搭建,這對於不少傳統研發團隊來講是一件很難的事情。
▌軟硬件資源及交付過程缺少統一管控
項目組在申請軟硬件資源時,缺少統一管控,各項目組獨立部署,沒法實現資源有效共享,資源利用率低,浪費嚴重。另外,在企業內部缺少統一的支撐平臺,每一個項目組從開發到上線,基本上都是從零開始,項目交付過程當中的沉澱不多,功能模塊沒法複用,交付過程也缺少統一,交付週期長,需求響應慢。
以上是Choerodon團隊在實踐過程當中遇到看到的狀況,這些狀況的存在可能致使研發團隊效能的低下,進而影響到用戶需求和價值的交付。對於研發團隊效能的問題,國際上的一些組織也有相關的研究和定義,DORA 與 Google Cloud 合做發佈的 2018 年《DevOps 現狀報告》中,將團隊根據 DORA 的軟件交付效能基準劃分爲三種類型:高效能、中效能與低效能團隊,以團隊產出來進行評價,發佈頻率、變動響應時間、服務恢復時間,以及變動故障率等指標做爲劃分的參考標準。其劃分標準以下:
對於低效能團隊如何改進才能進一步釋放潛能,提升團隊的效率,DORA 的研究強調技術轉型實踐相當重要。這些重要的實踐包括版本控制,自動化部署,持續集成(CI),基於主幹的開發以及鬆耦合架構。 今年DORA還發現,有助於持續交付(CD)的實踐包括:使用監控和可觀察性解決方案,持續測試,將數據庫更改集成到這樣的軟件交付流程中,以及關注安全性。
對於通常軟件研發類項目,每每包含產品立項、需求分析、應用設計,以及開發 、測試、持續部署與發佈,生產運維等。本節將給你們闡述,Choerodon豬齒魚是如何支持整個研發過程的,以及採用哪些手段來提升軟件交付的效率。
產品立項是啓動產品研發的第一個階段,最核心的工做是要肯定產品的定位,包括目標用戶、用戶須要、產品名稱、產品類型、關鍵優勢、主要競品、主要不一樣,以及相關成本投入、團隊建設等。此時,可使用Choerodon豬齒魚的知識管理功能,方便的記錄產品立項階段的各類輸出文檔。
▌需求分析
針對產品立項中的要求(例如用戶須要、關鍵優勢)進行需求分析,作好用戶訪談等。此時,可使用Choerodon豬齒魚的知識管理功能,方便的記錄需求分析的各類輸出文檔。
▌應用設計
在應用設計階段,將設計應用藍圖,構建總體系統架構和指定分階段實施計劃等。此時,可使用Choerodon豬齒魚的知識管理功能,方便地記錄應用設計階段的各類輸出文檔。
知識管理是一個輕量級的強大Wiki平臺,容許用戶根據本身的特定需求自定義Wiki,爲企業、IT團隊提供方便的項目協做平臺和強大的項目內容管理平臺,集中式管理產品相關內容等,例如需求收集、架構設計、功能設計、開發規範、命名規範、會議記錄、計劃安排等。
▌開發
在項目進入開發階段,主要進行代碼開發、單元測試、分支管理和版本控制等。Choerodon的開發流水線採用Gitlab CI做爲持續集成工具,研發團隊能夠進行代碼託管、分支管理、版本控制,有效簡化應用開發、縮短應用生命週期,快速迭代。
▌測試
在測試過程當中,團隊須要進行測試用例管理、測試計劃和執行,以及測試分析等。Choerodon的測試管理爲用戶提供敏捷化的持續測試工具,包括測試用例管理、測試循環、測試分析等,能夠有效地提升軟件測試的效率和質量,提升測試的靈活性和可視化水平,最終減小測試時間,讓用戶將主要精力放到軟件功能構建上。
▌持續部署與發佈
持續部署與發佈是採用自動化的手段,持續地發佈可部署的系統版本,並可以實現方便自動地將系統版本部署到目標環境中。此過程能夠藉助Choerodon豬齒魚的部署流水線,方便地管理各類使用Choerodon開發部署的應用服務和資源,包括一鍵部署、應用啓停、狀態監控,以及應容器管理等。
▌生產運維
在生產運維階段要對系統進行監控等,能夠藉助Choerndon的運營管理服務,其提供一整套完整的運營管理工具,在軟件交付生產的各個環節創建數據收集和度量,監控主要包含開發類指標、服務器日誌、應用系統日誌和微服務調用鏈等信息;同時,提供各類分析報告,幫助用戶優化IT資源配置。
另外,還有項目管理,項目管理貫穿整個產品的研發週期,藉助Choerodon的敏捷管理服務,經過故事地圖、用戶故事來管理用戶故事和發佈計劃,經過迭代來管理衝刺,最後經過看板來可視化衝刺的執行,讓需求、計劃、執行一目瞭然,使整個軟件開發流程管理規範化。
而且,Choerodon豬齒魚提供了一套基於Spring Cloud的微服務開發框架,在其中,作了大量的集成和封裝,預置了權限、數據一致性、登陸、前端UI 、審批、系統管理、我的中心等諸多模塊,可讓用戶專一基於業務的實現開發。
在遷移以前,系統架構師或者軟件工程師對Choerodon豬齒魚可能有一些疑問,例如,Choerodon是否有編程語言限制,對數據庫的支持狀況怎麼樣,是否支持公有云等。下面就對於廣泛的疑問,一一做答。
Choerodon豬齒魚的核心部分是一個PaaS平臺,採用Sping Cloud微服務架構進行開發構建。根據Choerodon豬齒魚的設計思路,只要是可以容器化的應用均可以使用Choerodon的PaaS平臺進行開發和部署,應用自己能夠採用不一樣的編程語言,例如Java、C、C++、C#、Python、Go,以及由編程語言衍生出來的各類開發框架,例如Spring Cloud、Spring、Struts、Mybatis、Django、Flask、ReactJs、AngularJs等(這裏不一一列舉)。
Choerodon豬齒魚一個核心的特性是經過鏡像和容器實現「不可變架構」,不可變架構的好處是在程序開發階段生成的可部署版本是鏡像,在鏡像中已經作過系統須要的各類設置,可直接經過鏡像生成部署容器,無論是開發環境、測試環境仍是正式環境,鏡像不可變化,即全部環境的系統設置是一致的,避免不一致致使的各類系統問題。
Choerodon的開發流水線結束生成後將生成版本化的鏡像和相關的配置文件,在部署階段,直接將鏡像部署到Kubernetes集羣中,因此,若是要使用Choerodon豬齒魚的部署功能,應用程序必須容器化。
軟件系統通常分爲應用層(前端、後端)和數據庫層,以及部署相關,Choerodon豬齒魚主要覆蓋應用層,以及部署相關的容器層,如今尚未覆蓋數據庫層的相關內容。對於數據庫層,用戶能夠選擇自建或者是使用公有云的RDS服務。另外,程序中依然可使用自動化的腳本構建數據庫和初始化數據等,與原來沒有任何區別。
目前很流行先後端分離的架構,例如後端使用SSM,前端採用React、Ant Design,移動端採用React Native等。Choerodon豬齒魚徹底支持這樣的先後端分離架構,其實仍是那句話「只要是可以容器化的應用均可以使用Choerodon的PaaS平臺進行開發和部署」。
微服務是目前很是流行的技術之一,表明有Spring Cloud、Dubbo等。如今你們在談微服務的時候必定要加上Agile/DevOps,貌似微服務+Agile/DevOps是不可分割的總體。根據實踐經驗,微服務的實施和落地須要從項目管理,開發,部署,運營監控,以及容器化等多個方面來考慮和配套。Choerodon豬齒魚其實是因微服務而生,有一整套完整的工具鏈條來支撐微服務的實施和落地。
如今有各類移動應用技術,如React Native,Weex,PWA等。用這些或者別的框架開發的模塊應用,只要可以打包成一個文件而且可以在原生應用中使用的,就能夠經過Choerodon豬齒魚進行移動微服務的版本跟蹤、發佈、回退甚至是根據不一樣主版本號進行個性化定製。
可是總應用的開發(通常用原生的Java或者OC或者Swift來開發原生應用)做爲一個前置條件,是不經過微服務管理的(由於每每要涉及到應用的審覈、推送、上架等),因此這裏說的移動應用微服務化是指其中的模塊應用。總應用只要可以實現文件的下載、覆蓋,版本的對比便可。
若是總應用開發完成,在平常開發中開發人員要作的只是獨立的模塊開發,推送到Git庫,觸發CI,這時會生成模塊的鏡像並推送,而後在Choerodon豬齒魚中選擇是否可見和版本管理,便可在手機的應用上查看或者更新該模塊。
Choerodon豬齒魚是基於Kubernetes部署的,只要是可以安裝部署Kubernetes就能夠安裝使用豬齒魚,因此公有云、私有云或者混合雲,只要安裝了Kubernetes,就能夠安裝使用Choerodon豬齒魚,另外,對於公有云中提供的RDS、NFS等服務Choerodon也可使用,可是對於公有云提供的Kubernetes服務,阿里雲、騰訊雲的K8s服務是沒有問題的,AWS的K8s服務可能有問題,由於AWS的Kubernetes服務是通過客戶化的與開源版本的可能有所不一樣。
Choerodon豬齒魚採用DevOps的原則和敏捷模型來管理軟件的開發和運維,能夠有效提升軟件交付的質量(好比:提升可用性,提升變動成功率,減小故障等),加快產品推向市場(好比:縮短開發週期時間和更高的部署頻率),而且提升組織的有效性(好比:將時間花在價值增長活動中,減小浪費,同時交付更多的價值至客戶手中),有效地幫助企業或者組織提高IT效能。
在第二篇文章《如何將現有的應用遷移到Choerodon豬齒魚(下)》中,將詳細的介紹將現有的應用遷移到Choerodon豬齒魚的詳細步驟。
Choerodon豬齒魚是一個開源企業服務平臺,是基於Kubernetes的容器編排和管理能力,整合DevOps工具鏈、微服務和移動應用框架,來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺,同時提供IoT、支付、數據、智能洞察、企業應用市場等業務組件,致力幫助企業聚焦於業務,加速數字化轉型。
你們能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性,以及參與社區貢獻:
歡迎加入Choerodon豬齒魚社區,共同爲企業數字化服務打造一個開放的生態平臺。