- 《架構世界》2020金融刊：DevOps與微服務在金融業的應用
- 普元信息
- 1901字
- 2020-09-03 11:24:17
．在金融行業落地都有哪些姿勢
我們先看看我們對于的定義：
? 持續集成，我們通常定義為從代碼提交到編譯打包，再到的過程
? 中的持續交付，我們通常定義為從代碼提交到的過程
? 但項目里，沒有用做的項目，也可變相為從編譯打包到的過程
? 中的持續部署，我們通常定義為從代碼提交到最后生產部署的全過程
? 但項目中，有可能變通為從編譯打包到生產部署的過程總結來看，項目結果不同，或者接入應用系統也有可能處于不同的階段，這造成了，/的過程隨項目實際情況會有些差異。
項目在售前、招標或前期階段，我們通常看到是小圈里面的內容：
/、自動化部署及回滾、與現有云平臺的接口、流程的圖形化編排調度等，但這些只是的內核，真正去落地一個項目的時候，其實你會看到外面大圈的這些內容，換句話講，需要梳理組織整個軟件生產的全過程！
姿勢一：小范圍+，再全公司推廣
先看看 的案例，美國第一資本金融公司，美國排名前十的銀行。
痛點：
年當時， 的軟件開發實踐和很多傳統做法沒有什么不同：大量外包，瀑布模型，季度發布，手工流程，變更請求。在某次代碼檢查會上，大家發現一個測試失敗是由于某個文件里的不配對造成的。按理說，這么小的問題改了再提交就可以了。但是：開發工作是由另外一家公司負責，他們需要發起漫長的變更請求；代碼修改后的構建流程（編譯、測試、部署等）就需要至少天時間。這個小小的問題讓 的技術團隊開始反思他們的構建流程，并決定從這里下手。他們從一個小的團隊開始實踐，最終把時間從天縮短到幾分鐘。于是，這個實踐逐漸在 蔓延開來，所謂星星之火，可以燎原。
年的成績：
. 代碼提交頻率：從之前的不固定到每天多次的提交
. 代碼集成頻率：從每月次到每分鐘一次
. 部署流程：手工變成自動化
. 部署到和（性能）環境頻率：從每月次到每天次
. 部署到生產環境頻率：從每月或每個季度次到每個迭代次
. 單元測試覆蓋：從沒概念到>%
年的成績：
. 發布到產品環境的頻率：從每個迭代一次到每天至少次
. 自動發布的應用軟件數量達個
. 一個應用軟件每天最多可以發布次
總結在 的落地姿勢：先小范圍做全套，再全公司大范圍推廣。
某壽險也是用的姿勢一：他們是與基于 的微服務體系架構一起引入的，原來的想法只是對于這些新的微服務的應用適用，經過半年的時間之后，感覺還不錯，就將逐步向傳統單體架構的應用中去推廣了。表中的系統是目前已經接入到中的系統。對接的代碼庫有//，介質庫是，和的流程目前還是做手工觸發，集成了和 單元測試，已包含測試和生產環境。組件包含：、腳本和 類，主要是全量的部署方式。
再總結一下：先小范圍適用+，它是現在微服務架構適用的，取得經驗積累之后，再大范圍的推廣。
姿勢二：先，后
我們看看某銀行的案例
在項目之初，某銀行首先對軟件生產的全流程進行了重新梳理和規劃，其中包含流程、規范、度量體系和反饋機制。
在實踐階段分了三步走，研發層面的持續集成、運維層面的持續交付，最終打通研發和運維實現全流程。
從試點效果來看，單就自動化部署層面就比之前提高了-倍的效率。并且在軟件質量和規范落實層面有了長足的進步。
再來一個以姿勢二落地的，某國家政策性銀行。
它的科技局下屬研發中心和運行中心是分開的兩個大部門，兩個部門之間的紐帶就是介質，但之前代碼基線與生產環境的介質版本一直對不上，這對生產的修復、災備部署都形成了很大困擾，所以它的研發中心引入是希望能形成統一的軟件出口，能夠將需求、代碼、配置、介質控制在同一個基線上。所以他們做法是先做，并且并行配合的框架推廣及的落地實施。但項目到了二期，它要引進建行建銀科技的新核心，一是新核心短時間內的多版本在多個測試環境的部署，二是配合改造的個業務系統短時間內也會有很多版本要快速部署，進行集成測試，這就要求必須有自動化部署的工具才行。所以二期的重點就定在了，主要是配合核心及配套改造系統提測后的快速自動化部署。
所以總結一下，落地的第二個姿勢：通常都是先由研發部門主導做，之后再推廣，最后將兩個流程串起來形成和的全流程。
姿勢三：先，后
這是一家地方商業銀行，也是因為今年要上新核心，并且伴隨新核心，有個系統要重新建設，套系統要配套改造，行領導提出的目標：在月日上線時，利用做一鍵式的統一部署！所以項目一期的重點就放在了上，短期目標是滿足多套系統的短期大量版本的提測后的自動化部署，最終目標，是要將++這些系統能夠可視化的一鍵式部署。項目的二期重點，是在，配合諸多研發管理的落地實施，全流程的應用和推廣以及自動化測試的接入。