SpareBank網路銀行實現微服務DevOps經驗分享 - Somaiah

• 可以在24小時內完成對生產的構想
• 程式碼可以在30分鐘內部署

1.程式碼庫分為可管理的塊
程式碼被分解為微服務架構 - 將功能從Weblogic monolith移植到透過單點登入Single Sign On令牌相互通訊的較小應用程式。有關詳細資訊，請觀看Stian和Vidar的精美JavaZone簡報。

2.開發人員分為自治團隊，在釋出，創新和編碼方面具有完全的自由。
使用Conway康威定律的逆版本，團隊根據網路銀行功能切分，才能反映新的架構。每個團隊都有自己的程式碼庫，並負責自己的版本。

3.每個開發人員都使用相同的環境。
每個開發人員在同一個作業系統上使用完全相同的設定，並在同一個IDE上使用程式碼。
建立分支，拉取請求，合併分支與內部構建器指令碼的開發一致，該指令碼自動執行分支建立，Jenkins建立作業等任務。例如，使用“begin”選項執行指令碼，在git上建立一個功能分支，並在構建和單元測試中建立相應的Jenkins作業。
Git鉤子確保分支不能合併，除非它們透過Pull請求，並獲得其他開發人員的相應批准。
批准Pull Request後，可以合併更改，並使用“complete”選項執行構建器指令碼以刪除功能分支和Jenkins作業。
擁有一致的開發環境可確保開發人員可以輕鬆地在團隊之間移動，如果他們願意的話。

4.每個應用程式共享相同的架構。
在從整體中分裂出來的20多個應用程式中，每個應用程式都具有相同的體系結構和檔案結構。前端和後端目錄和模組結構在不同應用程式中是一致的。
執行應用程式的框架的細節與領域程式碼分開。因此，如果來自其他團隊的開發人員進入，框架程式碼已經很熟悉了。

5.有一個共同的構建過程。
每個應用程式都包含一個構建腳 由於檔案結構和模組在應用程式之間是一致的，因此該構建指令碼在應用程式中大致相同。還記得開發人員啟動功能時由構建器指令碼建立的Jenkins作業嗎？所有這項工作都需要執行此構建指令碼。

6.對公共庫的依賴性會經常更新並自動更新。
每週更新對公共程式碼庫的依賴性。應用程式開發人員仍必須批准Pull Requests並手動合併更改，以避免無法預料的更改，但大部分依賴項更新都是自動的。

7.一切都是自動化的！
每次提交git都會觸發Jenkins構建。構建在功能分支上的是使用npm執行全套前端測試，使用jUnit執行後端測試。開發和釋出分支還與Finesse一起執行整合測試。
文件現在是原始碼的一部分，並在構建釋出分支時構建和打包。建立釋出版的開發人員必須做的唯一事情就是建立一個進入發行版的Jira ID列表（任務跟蹤工具）。
在釋出版本時，此列表將透過指令碼上載到匯合，這意味著釋出經理只需檢視Confluence頁面即可輕鬆檢視版本中涉及的Jira ID。
如您所見，整個釋出審批流程差不多已被取消。基礎架構組仍需要隨時瞭解計劃釋出的日期，這些版本的內容（作為Jira ID）和可能受影響的功能。這使他們為釋出後可能發生的事件做好準備。
根據Puppet的2018年DevOps報告，這是可以接受的：

擁有外部變更審批委員會對穩定性的影響可以忽略不計，但對敏捷性有不利影響。儘管有這些證據，但我們經常看到，做出決策的權力從擁有相關資訊並正在從事實際工作的人員中刪除。

8.一切都記錄下來！
對後端服務的呼叫記錄為JSON，這使日誌分析工具可以輕鬆索引事件。

9.提供同一個單個環境
伺服器現在已虛擬化，這意味著它們可以從指令碼例項化。這確保了每個環境 - 測試，QA，試驗和生產都具有相同的設定。

10.釋出由開發團隊自己執行
當程式碼透過單元，整合和系統測試時，開發人員自己可以選擇釋出它。該過程本身非常簡單，因為我們使用基於Web的部署平臺。所有這一切歸結為按名稱選擇應用程式，正確的版本號並單擊按鈕。
這個過程不會在一夜之間發生，甚至不會在幾周內發生。實際上，是在我們意識到哪些有效，哪些無效之前，經歷了幾次迭代以後。
兩週前，當我為營銷團隊釋出修復程式時，從瘋狂的電子郵件到生產部署的整個過程耗時1小時37分鐘。這包括完成每個測試階段，更新文件，部署和測試QA和試驗環境，最後最終耗費時間 - 在將部署版本部署到生產之前等待30分鐘的登入會話耗盡。
隨著我們邁向API和開放式銀行業務概念，我們的DevOps戰略將進一步發展。不可避免的雲端計算也將帶來自身的挑戰和回報。但是，過去幾年所做的改變將使我們能夠靈活地適應這些挑戰。
​​​​​​​