1、應用開發(fā)測試環(huán)境搭建最佳實踐 技術創(chuàng)新 變革未來一個故事：關于開發(fā)測試的環(huán)境1 Day10 Minutes發(fā)現(xiàn)問題分析問題解決問題服務的演進實際上迭代效率驟降測試質(zhì)量驟降、線上問題頻發(fā)潛在的弱安全性隨著業(yè)務越來越復雜，團隊越來越多，配合一次完整的環(huán)境搭建的時間近乎要 1 Day。迭代效率驟降測試原則： 每測試一輪，需要重新搭建環(huán)境 + 部署新代碼，重新驗證Test Case一個2周的迭代，花在環(huán)境上就要至少2天。 一個迭代周期內(nèi) 1/5 時間的都在搭環(huán)境。測試質(zhì)量驟降、線上問題頻發(fā)搭建成本升高使得 規(guī)避搭建環(huán)境，能對付就對付。非常規(guī)手段：已有環(huán)境，敝帚自珍，不忍重來沒有環(huán)境，拷貝別人的沒有環(huán)境

2、，借別人的 . 測試質(zhì)量驟降、線上問題頻發(fā)搭建成本升高使得 wiki和腳本開始不好使了 搭出來的環(huán)境也是壞的非常規(guī)手段越用越多wiki和腳本越用越少新增邏輯無法沉淀誤測： 測出一堆bug發(fā)現(xiàn)其實是環(huán)境問題漏測：測試環(huán)境沒問題，上線就有問題潛在的弱安全性私人數(shù)據(jù)庫，缺乏管理，敏感信息進入測試環(huán)境發(fā)現(xiàn)問題分析問題解決問題分析問題 四個痛點團隊壁壘可維護性差測試數(shù)據(jù)庫不便捷分析問題 - 團隊壁壘一個用戶端的項目想測試全流程對方的排期服務的聯(lián)調(diào)持續(xù)的溝通分析問題 - 團隊壁壘不要團隊合作，賦予每個人相同的權利對方的排期服務的聯(lián)調(diào)持續(xù)的溝通分析問題 - 可維護性差環(huán)境搭建腳本維護的是哪些東西？線上線下差

3、異分析問題 - 可維護性差搭建環(huán)境 1.0 怎么維護差異？以人為主，所有的都差異規(guī)則都依賴于人的自覺性新服務狂引入分析問題 - 數(shù)據(jù)庫問題不夠便利可用性差不安全不安全 站庫分離不徹底、任性的導數(shù)據(jù)不夠便利 上千張表，幾十個數(shù)據(jù)庫可用性差 本地服務、單點。分析問題 - 不夠便捷分析問題 - 不夠便捷這樣的從產(chǎn)品上，它必須是發(fā)現(xiàn)問題分析問題解決問題回顧問題有團隊壁壘可維護性差測試數(shù)據(jù)庫不便捷有團隊壁壘成立橫向的技術團隊，面向所有人做平臺，屏蔽業(yè)務的技術細節(jié)，提供整套服務。ALL用戶端商戶端物流端營銷訂單畫像.平臺化橫向技術團隊平臺技術架構提高可維護性整頓不合理的差異公共差異自動化個性化差異插件化提

4、高可維護性 - 整頓不合理的差異原則：線下要盡可能接近線上創(chuàng)造線下邏輯省略認為不必要的一些校驗繞過覺得麻煩的登錄直接連接服務圖方便寫死結(jié)果.提高可維護性 自動化和個性化RPC配置本地化要求線上服務端口唯一。遠程BNS直接做本地映射數(shù)據(jù)庫配置私有化根據(jù)用戶數(shù)據(jù)庫信息自動生成數(shù)據(jù)庫配置。個性差異插件化公共差異RPC配置數(shù)據(jù)庫配置Redis配置.個性差異支付密鑰第三方token域名替換.測試數(shù)據(jù)庫解決方案DataTest = 1 前提測試數(shù)據(jù)庫解決方案自動創(chuàng)建數(shù)據(jù)庫 - 統(tǒng)一導出條件 - 集中集群管理便捷如何做到一鍵更新測試機解決方案并行更新服務數(shù)據(jù)庫全選增量更新服務方式耗時用戶端服務（LNMP） 大?。?900M 替換600s用戶端服務（LNMP） 大?。?00M 增量30s平臺技術架構解決問題成立了橫向維護部隊，負責橫向的調(diào)研分析、制定方案、落地、售后服務。抽象并重構了所有業(yè)務團隊的搭建流程，并使之標準化，可擴展。形成了一個統(tǒng)一的平臺，我們給它起了一個簡單可愛的名字叫“樂高