首頁 > 移動應用 > 正文

面向移動應用程序的DevOps五大挑戰和十個最佳實踐

2020-02-07 18:37:08  來源:csdn

摘要:在過去五年中,許多行業在努力適應業務應用程序用戶行為的巨大轉變,因為全球數百萬人已采用移動設備作為其訪問互聯網的主要方式。
關鍵詞: DevOps
在過去五年中,許多行業在努力適應業務應用程序用戶行為的巨大轉變,因為全球數百萬人已采用移動設備作為其訪問互聯網的主要方式。用戶行為的這種重大轉變是企業為現有業務應用程序開發移動渠道的強大動力,也是為使用移動設備獨特特征的新應用程序類型制定計劃的強大動力。與 IT 行業的所有主要演變一樣,此轉變的最初幾年見證了滿足需求和建立市場地位的大量活動,但沒有考慮到更多的戰略問題,比如應用程序開發成本、可維護性、質量和安全性。隨著移動應用程序市場走向成熟,最初的市場高峰已趨于緩和,現在的焦點是更全面的軟件開發問題。

 

在本文中,我們介紹了在企業中集成移動應用程序所面臨的挑戰,并提供了移動 DevOps 的 10 個最佳實踐。我們首先將概述 DevOps,并解釋在 DevOps 商店中集成移動企業應用程序所面臨的一些具體挑戰(及其必要性)。接下來,我們提供了在工作流中實現 DevOps 的 10 個最佳實踐,以便將持續集成、應用程序測試和監控,以及移動應用程序交付結合起來。

 

什么是 DevOps?

 

DevOps 不是一種技術或流程,而是一種支持從開始到生產過程的無縫應用程序交付的方法。在 DevOps 出現之前,企業組織通常保持獨立的開發和運營團隊。團隊之間缺乏溝通和協作,這在很多方面阻礙了企業的發展和創新。對于采用敏捷開發的企業來說,最令他們苦惱的是開發和運營的分離,因為使用敏捷方法使要開發、測試和部署的新應用程序版本數量增加了數倍。開發人員能夠每隔幾個小時就生成出構建版本,并以更高的頻率提供發布候選版本,而不是每幾個月才能向運營團隊提供一個新構建版本。

 

DevOps 移動從開發和運營團隊協同工作以更有效地解決持續應用程序交付所面臨的挑戰開始。最初的目標是 “轉移” 運營責任,包括軟件交付生命周期早些時候的運營。接下來,鼓勵開發人員從開始編碼應用程序時就考慮運營因素。實際上,DevOps 會協調開發人員和運營經理的興趣和知識背景,方法是使用精簡開發的原則讓持續集成和持續交付流程變得更高效。

 

IBM 從整體的角度來看 DevOps,將它定義為企業的持續軟件交付能力,可讓客戶抓住市場機遇并縮短客戶的反饋時間。

 

此定義中的關鍵詞是持續交付。持續交付表示在軟件交付生命周期的任意階段自動根據需要部署軟件及其運行的環境。在持續交付中,您可能部署任何內容 — 從簡單的配置更改,到增量式代碼更改、數據庫模式更改,再到環境更改或整個堆棧的更改。

 

面向移動應用程序的 DevOps

 

無論是對企業 Web 應用程序進行編碼,還是對移動應用程序進行編碼,DevOps 都采用相同的基本原則。在為企業采用 DevOps 之前,請包含您的移動開發團隊,即使此移動團隊只是企業的一小部分或者是它采用了不同的軟件開發流程。如果您正在開發作為現有企業應用程序和服務前端的移動應用程序,那么更應如此。無論應用程序是面向客戶的還是僅供內部使用,都是如此。

 

與企業應用程序和服務直接交互的移動應用程序需要是 DevOps 生命周期的基本因素。向企業應用程序或服務添加新功能時,團隊可以將它們無縫地集成到移動應用程序。

 

移動 DevOps 挑戰

 

盡管企業和移動應用程序的 DevOps 基本原則是相同的,但是移動應用程序會提出具體的 DevOps 挑戰。這些挑戰包括:

 

多平臺支持

 

移動應用程序沒有一個環境目標。大多數移動應用程序都可以在多個設備上使用,這意味著要處理各種技術規范、操作系統版本和外觀因素。Android 以各自為政而出名,每個設備供應商都為其自己的設備創建了操作系統(示例包括 Android for Nexus、Android for Kindle Fire 和 Android for Nook)?,F在,BlackBerry 10、Windows® Phone 8、Ubuntu 和 Firefox 等新進入者進一步分裂了 Android 市場。同樣,曾經非常標準的 iOS 目前也具有多個變體。iOS 應用程序需要支持不同版本的 iOS;iPhone 4S 和更低的設備;iPhone 5,以及 iPad 和 iPad mini。

 

使用移動應用程序作為企業前端

 

移動應用程序,尤其是企業 B2C 或 B2E 移動應用程序,通常在移動設備上沒有什么業務邏輯。相反,企業已使用 B2C 或 B2E 移動應用程序作為一個或多個企業應用程序的前端,比如事務處理系統、員工人力資源系統或客戶獲取系統。圖 1 突出顯示了本身具有有限業務邏輯的應用程序。

 

 

圖 1. LinkedIn 移動應用程序的結構

 

LinkedIn 移動應用程序是后端 LinkedIn Platform(包含 LinkedIn 的 Profile、Connections 和 Groups 應用程序或服務)的前端。移動應用程序(作為一個原生或混合應用程序提供給多個平臺)需要后端 LinkedIn Platform 服務一起開發和交付。對于 DevOps,挑戰是全面思考企業中的所有應用程序并協調器構建和版本流程與周期。

 

持續集成和持續交付

 

由于想要將移動應用程序快速推向市場,因此移動開發項目通常具有非常緊迫的時限。從啟動到交付通常需要幾個月或幾周的時間??焖俳桓兑苿討贸绦虻膲毫ζ仁谷藗儾捎妹艚蓍_發方法來實現最成功的移動項目。

 

持續集成和持續交付是所有敏捷項目的重要元素。對于所有目標移動操作系統來說,必須立即處理開發人員提交的應用程序更改。如果移動應用程序是混合或本機實現,那么每次開發人員交付應用程序更改集時都會觸發幾個不同的應用程序版本。所支持的移動環境的構建設置和配置各不相同。您很可能需要配置一個小型構建服務器場,并使用它們來處理多個操作系統構建版本。

 

應用商店

 

在大多數情況下,無法將移動應用程序直接部署到設備上。必須使用應用商店。Apple 引入了此應用程序分發模式,并鎖定其設備以避免應用程序開發人員或供應商直接安裝應用程序。RIM 等設備制造商也紛紛效仿這一做法。

 

應用商店為部署流程添加了一個額外的異步步驟,因為開發人員不能按需部署應用程序更新。即使對于關鍵的 bug 修復,新的應用程序版本也必須經過應用商店提交和審核流程。持續交付變為 “提交并等待”。

 

‘拉' 而不是 ‘推' 部署

 

大多數傳統部署以 “推” 模式運行,而運營可以按需推出一個新應用程序版本,無論它是 Web 應用程序還是其他任何基于服務器的應用程序。更新移動應用程序的流程是 “拉” 流程,但是在大多數情況下,用戶必須自己選擇更新應用程序。移動應用程序開發人員難以控制用戶在其設備上使用的應用程序版本。從開發運營的角度來看,這意味著已部署的后端服務(與應用程序交互)必須為之前的移動應用程序版本提供持續支持。

 

對于消費者應用程序,失敗不是一個選擇

 

對于品牌來說,沒有比應用程序的評級為 1 星更糟糕的事情了,尤其是評級通過應用商店媒介傳播時。如果用戶對消費者移動應用程序不滿意,那么公眾很快就會知道這一消息,無論應用程序是付費的還是免費提供的。盡管網站投訴問題會提交給技術支持服務臺,但是移動應用程序投訴會通過應用商店進行傳播,所有人都能看到這些投訴。移動應用程序必須經過大量功能性、可用性和性能測試來保證其質量。

 

移動DevOps的10 個最佳實踐

 

根據移動應用程序所面臨的具體挑戰,我們推薦了 10 個面向移動應用程序的 DevOps 最佳實踐。這些實踐按照功能可分為三大類,即:

 

  1. 持續集成和持續交付

  2. 測試和監控

  3. 移動應用程序交付

 

我們的目標是使用 10 個最佳實踐來創建一個支持這三種功能的交付管道,同時解決移動應用程序所面臨的具體挑戰。

 

DevOps 的理論和實踐

 

DevOps 交付管道實現 DevOps 的技術方面,但它對滿足 DevOps 移動的人文和文化方面也很重要。本部分的最佳實踐旨在確保企業將移動開發和 QA 團隊作為其 DevOps 社區的重要組成部分。整體 DevOps 哲學必須考慮移動應用程序開發團隊(與開發企業 Web 應用程序和服務的團隊合作)的需求和關注事項。

 

持續集成和持續交付

 

確保所有資產的端到端可追溯性。所有開發和 QA 資產的可追溯性值不再是一個爭議不斷的主題。移動應用程序開發團隊必須確保所有開發資產的端到端可追溯性 — 比如代碼、配置、腳本、基礎架構即代碼、測試腳本和設計文檔??勺匪菪圆⒉粌H限于移動開發資產也很有必要;它必須能夠擴展到移動應用程序與之進行集成、連接或訪問的企業應用程序和服務。

 

持續集成實踐。敏捷開發實踐宣揚持續集成,這意味著運行頻繁的構建版本,并將新代碼與其他團隊之前開發的代碼集成在起來 — 移動和企業應用程序。持續集成確保一個開發團隊交付的代碼與其他開發團隊交付的代碼和模塊一起工作。對移動應用程序來說,通常會持續地執行集成。也可以使用組成后端(正在開發的移動應用程序可以訪問它)的非移動服務器端組件定期執行集成。

 

對于移動應用程序,開發團隊將會共享移動應用程序代碼(為所有目標移動平臺提供服務)的中央構建和集成服務器。自動化構建和開發流程可確保提供快速而又可靠的持續集成構建,這些構建在所有受支持平臺的中央構建服務器或服務器場上執行。

 

為受支持的每個本機移動操作系統 SDK 版本保持獨立的構建和集成區域。移動設備領域的分裂延伸到了 iOS、Android、Blackberry 和 Windows Phone 這 4 種主要移動操作系統之外;每種操作系統的內部也是分裂的。Apple 創建了其自己的操作系統來支持 iPad。Android 幾乎為每種設備創建了一個變體。RIM 的 BlackBerry 10 是一個全新的操作系統,與舊 BlackBerry OS 的關系并不大。Windows Phone 8 是之前的 Windows Phone 的重大重組。還出現了一些新的移動平臺,包括來自 Ubuntu 和 Firefox 的移動平臺。因此,移動應用程序開發人員必須編寫多種應用程序變體來支持每種目標平臺及其變體,即使它們只針對一個目標平臺也是如此。每個移動應用程序都需要多個 SDK 版本。

 

要確保代碼和每種目標平臺的具體功能相分離,開發人員必須為移動應用程序的每個特定平臺版本保持獨立的開發 “流”。這就需要針對每個目標平臺保持獨立的構建和集成區域。如果是 Android 應用程序,那么開發人員需要針對 Kindle Fire、Nook HD、Nexus 和其他操作系統保持獨立的流。

 

使用自動化的構建和部署腳本。移動開發人員已習慣使用 IDE 手動運行構建版本。他們通常手動運行構建版本,在某些情況下,將針對不同的目標平臺運行構建版本。隨著構建版本的數量和復雜性不斷增加,開發人員可以設置自動構建版本,方法是使用腳本根據需要在獨立的構建服務器上運行構建版本。管理構建腳本和分配版本的方式與代碼類似,都要確保任意團隊成員隨時都可以重現每個構建版本。

 

測試和監控

 

在模擬和物理設備上盡可能自動對每個構建版本進行全面測試。測試自動化是移動應用程序開發落后于企業應用程序的地方。大多數移動開發人員在模擬器而不是物理設備上進行廣泛測試。模擬器上的測試大部分是手動的??紤]到開發的速度和移動開發的敏捷本質,自動化的功能回歸測試是保證質量的唯一方式??紤]到所支持的各種平臺和外形,通過手動方式進行足夠的測試不太可能。此外,對于企業應用程序來說,無論它們是用于客戶還是員工,質量低劣都是不能接受的。

 

使用自動測試工具在 SDK 提供的模擬器上和受支持的所有實際物理設備上測試所有應用程序。

 

虛擬化和模擬移動應用程序測試期間不可用的后端服務。移動應用程序遵循快速開發流程,與后端企業應用程序和服務相比,這會生成更多的版本。此類快速開發可以讓移動應用程序在技術方面領先于企業應用程序,這意味著它們擁有后端企業應用程序和服務還不支持的新功能。即使在后端服務可用時,可能也需要花費金錢或資源來對它們進行測試。例如,SaaS 服務通常有按使用付費的成本,即使是測試也是如此。同樣,System z (mainframe)-托管服務也有 MIPS 成本。開發團隊還可以通過虛擬化(模擬)后端服務來解決這一問題。與移動應用程序進行交互的整個應用程序、服務和數據來源生態系統,可以作為虛擬實例提供,模擬移動應用程序需要進行交互的實際功能行為。這種安排可以快速測試移動應用程序及其交互。還可以節省運行這些服務和應用程序的實際實例所需的硬件資源。

 

監控已部署的移動應用程序和后端服務的性能。移動應用程序開發人員面臨的最大挑戰是應用程序在測試環境中運行良好,但在實際使用中卻出現了故障。不可靠的網絡環境、內存低、電力不足和數據丟失是移動應用程序性能差的一些根本原因。在實驗室中,并不是所有這些情況都是可以預測和測試的,因此當務之急是開發人員應在使用應用程序時啟用持續性能監控??梢栽趹贸绦蛑谢蚺c應用程序交互的應用程序堆棧服務器端進行監控。

 

當用戶實際使用時移動應用程序停止運行,則會出現最終性能故障。出現故障時,為捕獲 “必須收集” 的上下文信息的應用程序添加邏輯,比如位置數據和設備特性,并為開發人員提供足夠的數據來查找故障的根本原因并糾正它。嵌入式崩潰捕獲和分析邏輯是移動應用程序的重要組件。

 

移動應用程序交付

 

為移動配置概要文件、認證和 API 密鑰采用集中管理。無論是將應用程序提交到應用商店,還是使用內部或外部應用程序提供的 API,開發人員或公司都可以通過供應商發布的配置或配置文件密鑰來確定應用程序的真實性和所有權。這些密鑰可以充當商店或 API 的授權階段。通常,各個開發人員會單獨獲得他們用于開發的密鑰。但是,當發布最終應用程序時,會刪除所有這些個人密鑰并使用官方企業密鑰替換它們。保護企業密鑰和配置文件,并且只將它們用于官方應用程序版本。必須良好地定義和控制移動管理流程。最重要的是,限制對企業密鑰的訪問。授權是一個需要嚴格管理的安全和隱私問題。

 

使用虛擬應用商店測試設備部署。只能通過供應商的應用商店將移動應用程序配置到移動設備。通常,在應用程序進入應用商店之前,會經過一個手動審批流程。在將應用程序放入商店后,用戶需要 “購買” 應用程序,然后將應用程序部署到設備上。要測試整個過程,開發團隊可以使用一個 “專有開發應用商店”。這些虛擬應用商店(請參見 參考資料)模擬了真實應用商店的行為,允許開發人員有效地測試提交應用程序的過程,并將應用程序配置到設備上。

 

將用戶反饋轉換為改進請求和用戶案例。移動應用程序有一個通過應用商店進行反饋的獨特機制,允許用戶評級并提供書面反饋。深受歡迎的應用程序可能會得到 4 星或 5 星評級。不受歡迎的應用程序通常會得到 1 星或 2 星評級,可能還伴隨著負面反饋。移動應用程序的反饋循環不可以作為其他任何平臺的正式集中機制。通常情況下,只有在用戶請求技術支持或在開發人員監控的論壇上留下評論時,開發人員才會發現有關桌面應用程序的問題。移動開發團隊應該密切監控應用商店反饋和評級,并將反饋納入未來的用戶案例、增強和軟件改進中。充分利用此寶貴反饋是持續改進移動應用程序必須做的事。

 

結束語

 

面向移動應用程序的DevOps是獨一無二的。DevOps是一種適用于所有應用程序和組件的方法 — 從前端移動應用程序,到中間件,再到后端服務器組件和數據存儲。企業中的所有開發和運營團隊都應用DevOps實踐和原則來支持所有組件的持續開發。

 

移動應用程序有一些必須解決的具體需求和挑戰。我們的 10 個面向移動應用程序的 DevOps 最佳實踐解決了這些特定于移動的需求。這些最佳實踐的目的是讓移動應用程序開發、質量保證和運營實踐與標準的企業應用程序保持一致。利用這些最佳實踐,企業可以在其移動開發團隊中采用 DevOps,交付高質量的移動應用程序,并支持持續改進和創新。


第三十屆CIO班招生
法國布雷斯特商學院碩士班招生
北達軟EXIN網絡空間與IT安全基礎認證培訓
北達軟EXIN DevOps Professional認證培訓
責編:chenjian
济州岛赌场