由蘋果的4種版本想到的

根據渠道（企業和蘋果市場）和模式（Debug和Release）兩個維度組合，可以有4種不同的版本組合。

1. AppStore渠道Debug模式

• 這是最常用的模式，一般就是所謂的開發版

• 用開發證照

• 測試手機的UUID需要上傳蘋果網站

• 可以用XCode連線測試機除錯，設定斷點等

• 可以用iTools等工具在測試機上安裝

• 沒有註冊UUID的手機不能用

2. AppStore渠道Release模式

• 這是通常所說的產線版本

• 用釋出證照

• 不能用XCode除錯，不能設定斷點

• 不過可以通過XCode安裝。執行時會閃出來

• 不能用iTools等工具在手機上安裝

• 只能從AppStore下載安裝

3. 企業渠道Debug模式

• 299美元/年的賬號

• 用開發證照

• 測試手機的UUID需要上傳蘋果網站

• 可以用XCode連線測試機除錯，設定斷點等

• 可以用iTools等工具在測試機上安裝

• 沒有註冊UUID的手機不能用

• 是企業版的“開發版”

• 與普通的開發版bundle id不一樣，相當於不同的應用。

• 這個模式也是給開發人員用的

4. 企業渠道Release模式

• 這是通常所說的“企業版”、“內測版”、“搶鮮版”

• 用釋出證照

• 不能用XCode除錯，不能設定斷點

• 不過可以通過XCode安裝。執行時會閃出來

• 能用iTools等工具在手機上安裝，手機不需要註冊UUID

• 也可以放在企業內網，下載安裝

• 不能上傳AppStore

關於友盟統計

• 一開始，友盟統計的AppKey是跟bundle id相關的；這樣的話，引入企業版就要申請新的AppKey

• 估計企業版用於內測比較多，除了bundle id不一樣，其他功能跟正式版都一樣，那麼把bundle id作為區分條件就不合適

• 當前的友盟統計的AppKey跟bundle id無關；這樣的話可以自己決定是否需要新建AppKey。
  簡單處理就不要新增了，跟正式版用同一個；
  如果要區分渠道：正式的還是內測的，那麼就新建一個。

關於分享

• 新浪微博分享，一個AppKey下面可以掛最多4個bundle id，所以可以不新增。

• 微信分享，一個AppKey可以掛2個bundle id，另外一個的名字叫測試bundle id。看來是專門用來拿企業版當內測版的

• QQ分享，有AppKey和AppID兩個引數，不知道為什麼這麼設計。從網站介紹來看，AppID好像跟bundle id有關。經過實際試驗，其實他的處理方式和友盟統計一樣：AppID和bundle id無關

• 小結：微博，QQ，微信這三個分享，都可以做到企業版和正式版用相同的AppKey，可以簡單地把企業版當做“內測版”。
  當然，如果要精細化管理，區分資料來源，那麼用不同的AppKey來做也是可以的。只是模式太多，版本太多，管理上面要多花點心思。

關於極光推送

這個沒有辦法，需要上傳推送證照。所以AppKey跟bundle id是強相關的。這種相關是蘋果的證照生成方式決定的，在可預期的未來也很難改變。
企業版和正式版，是完全不同的應用，雖然功能是完全一樣的。

需要幾個版本？

1. 開發版：（AppStore Debug模式）開發和測試使用，測試負責維護伺服器資料。開發可以用工具造資料，比如Charles；也可以在本地自己寫測試資料，只是不要忘了到時候刪除測試程式碼。建議的方式還是測試和開發合作，由測試提供核心案例資料，開發和測試標準統一。

2. 內測版：（企業賬號 Release模式）一般有兩種用法：（1）測試維護，用來測試和內部驗收。（2）運營維護，真正的內測版，伺服器環境和正式版本一致，但是獨立的伺服器，和正式環境隔離。

3. 稽核版：（AppStore Release模式）這個版本專門給蘋果稽核用。伺服器環境和正式版本一致，但是獨立的伺服器，並且只是1個或者2個測試賬號，（使用者數最好不要超過10個），註冊，簡訊驗證碼之類的流程都不要產生。並且，面對稽核，有些特殊的要求，比如IPv6伺服器等等。同時，蘋果稽核通過之後，不能自動上架，要手動上架。伺服器的開關切換放在後臺，手動上架前要把伺服器地址切換到正式的。

4. 正式版：（AppStore Release模式）。這是“產線版”，基本上都是有的。

大前端趨勢

• JavaScript有一統江湖的跡象，iOS、Android開發都準備轉JavaScript前端開發，至少思想上需要有這樣的趨勢。

• facebook 的React Native； 阿里的 weex， Google的 PWA，這些大公司都在跟蘋果爭奪開發者。iOS開發者地位下降，需求降低，薪資走低，蘋果的影響力控制力降低，這些都是正在發生的事情。
  庫克比賈伯斯差的不是一點點，從iOS開發者的生存狀態就可以看出來。

• PC 前端：主要是瀏覽器的網站

• H5 前端：微信小程式，支付寶生活號，微信公眾號，App中的活動，也可以嘗試一下 Google的 PWA

• App開發：iOS、Android元件開發，這些還是原生的。facebook 的React Native， 阿里的 weex選擇一個。以前用H5寫的活動頁面，也可以用weex（或者React Native）來實現。

• 閘道器開發：大前端裡面的後臺，後端系統的前端介面層。採用Node.js來做，也是JavaScript。這一層的價值是“大前端”和“大後端”之間的介面層。與後端，是純的“資料介面”；這一層主要是負責對各端資料格式做適配（比如瀏覽器的換行是<br />，原生的換行是\n）。

建議的流程

改進點：一般都是後臺系統準備好了，在提供資料給前端聯調，導致前鬆後緊，為上線加班。現在將整個流程分為內部發布，內部試用，蘋果稽核，正式上線4個階段，減少無意義的加班。

1. 內部發布:在開發分支上開發新特性，develop，資料由“閘道器開發”提供。能接實際後臺的就接上，比如使用者系統。後臺提供不了的，那麼就由測試根據核心測試案例構造一些，直接以url為key，value就是前端需要的json，直接放在“快取資料庫”中。保證各端都是可用的產品，沒有本地寫死的Demo資料。開發測試完成之後，就可以內部發布，將版本轉移到釋出分支。格式為alpha-年年月月日日。產品部門可以驗收，試用，看看是否符合設計，完成後就可以進入下一個開發週期。一個週期建議4周（1周理解需求和方案設計，2周開發測試，1周和產品部分交流合作，並未下個研發週期做準備）。當然，採用2周的開發週期也是可以的，只是要求部門間配合要做好。

2. 內部試用：這個要看後臺的進度。那些由“閘道器開發”提供的臨時json資料都接上真正的後臺資料，再經過測試驗證，就可以釋出“內測版”。這個內測版最好使用企業版賬號的Release模式。這個階段主要是後臺開發的實現以及“閘道器開發”介面的調整。前端方面，只要將某個合適的alpha-年年月月日日轉以為beta-年年月月日日就可以了。當然，由於接上真正的後臺，可能會導致前端的調整。並且這段時間也會發現新的bug，只需要直接在beta-年年月月日日這個分支上修改。至於修改是否同步到develop分支，要根據具體情況而定。
   “內部試用版”由於採用了企業版賬號，就比較靈活，可以直接放在自己的網站上（需要支援https），讓相關人員下載試用。這個版本的伺服器獨立，各方面和真實伺服器一致，主要由運營負責。一些活動，一些推廣的方案，可以內部先試用一下，看看效果，及時調整。試用的時間長短，是否正式推向市場，這裡還有討論和調整的機會。

3. 蘋果稽核：經過內部試用，終於決定上線了。蘋果稽核與正式使用的場景還是有很大差異的。前端的程式碼是一樣的，從某個beta-年年月月日日轉到release-年年月月日日就可以了。伺服器要單獨提供一個，配置和正式的一樣，不過要為稽核做一些特殊處理。比如支援IPv6，提供測試賬號，不能出現Android字樣等等。為了滿足蘋果稽核要求，可能會需要做一些修改，直接在release-年年月月日日分支上操作就可以了。至於是否將修改同步到develop分支，要根據具體情況而定。

4. 正式上線：經過等待和必要的修改，蘋果稽核通過了。（1）運營或者運維登入自己的後臺，將伺服器從蘋果稽核伺服器切換到正式伺服器。如果使用者量大，或者考慮穩定性，這裡可以引入“灰度釋出”，逐步放開使用者量。（2）登入蘋果開發者網站，手動上架產品。
   將上架產品對應release-年年月月日日，合併到master分支。如果由"灰度釋出"機制，需要等使用者全量放開才能合併。這段時間如果發現bug需要修改，直接在這個release-年年月月日日分支上操作。這裡的修改是否合併到develop分支，需要根據具體情況而定。
   合併到master分支，意味著一個完整週期走完了。master分支和穩定的正式版本保持一致。

master分支和develop分支是必須的，不可刪除，許可權要特殊控制。alpha/beta/release-年年月月日日都屬於中間輔助分支，保留一段時間後，比如半年，可以刪除。當然，都留著也是好的，每個過程都有里程碑標誌，方便追溯。

一開始，要錯開步驟，需要一點啟動時間，看起來要慢一點。完整執行起來之後，各個過程是完全獨立的，並且各自負責的部門主體也不一樣，是完全可以並行的，一點也不慢。

這裡的本質是前端能夠提供一個最小可用版本，按照自己的節奏發展，不需要乾等後臺資料。（依賴後臺資料的後果：前面沒法做，後面累成狗，加班上線後還要解線上bug，還有臨時的需求變更.... ）。

核心優勢1：技術和產品合作，倒逼運營養成提前規劃的習慣。反問：2周前提出，2周後就上線，這樣匆忙能作出一個好的活動嗎？風險能控制嗎？阿里的雙十一會這麼做嗎？

核心優勢2：方便領導審批。一份word文件就讓領導放成千上百的資金，壓力大嗎？如果領導能夠看到可用的產品（alpha版本），是不是審批時可以簡單點？

核心優勢3：風險提前發現。推出給終端使用者之前，先在公司內部試用一段時間（beta版），就算一週或者兩三天也比沒有強，是不是更能控制風險，對使用者更加負責？這個是不是比光靠測試把控產品質量更靠譜一點？

核心優勢4：更多試錯的機會。運營策劃一個活動之後，可以和產品和技術商量，大家覺得可行，就可以先開發出一個版本看看效果（alpha版），不需要等領導審批之後再動。有實際可用的產品，領導審批也更方便，也更容易過。（alpha版）不涉及後臺開發，就算廢掉，成本也不高。試錯機會多了，出好產品的概率會高一點。

核心優勢5：更快的迭代速度。不用等後臺實現，迭代版本速度就可以加快。前端和產品可以更緊密合作，加快產品演進速度。到使用者手裡的版本，在公司內部可能已經更新了三四個版本了。至少不會出現“最近後臺任務比較重，前端任務比較少，只能乾等著的情況。”

組織架構

技術架構和流程，需要相應的組織架構來支援。組織架構，還是採用傳統的分層模式，這個穩定，有歸屬感。而具體做事的時候，採用4~10人的小團隊模式，這個靈活，以團隊目標為主，防止個人英雄主義。

組織架構圖.png

• 產品一開始人少，可能就1~2個，可以先掛在技術下面。並且和客戶端團隊走得近，對以後的小團隊模式有幫助。發展壯大之後，一般會獨立成一個部門。形成產品，技術，運營的三角關係。

• “Node.js閘道器”和“客戶端資料服務”這兩個是客戶端和後端的介面，也是將兩者分離的交接點，是兩位負責人最需要關心的地方。一方面，統一出口，前後端隔離；另一方面，等使用者量大起來之後，要注意單點風險。所以這兩個模組，要定義需要做什麼，更要定義不做什麼。公共部分要做，具體實現儘量甩出去

• CTO應該是純管理，怎麼和CEO配合好事首要問題。當然，技術方向也要把控。

• 客戶端負責人和後端負責人，一般是前後端的架構師兼任。屬於重要的中層。以流程管理和架構技術為主，跟緊發展潮流，同時也應該花30%左右的時間做技術實踐，保持熟練度。

• 測試和運維屬於公共服務，可以單獨出來

• iOS和Android，面對的是兩種手機客戶端。可以先各找一個，當然也可以先發展一個，等穩定了再上另外一個。介面和互動，兩個端也不需要強調一致。兩種手機發展理念是不一樣的。

• H5，可以是App中的WebView頁面，也可以是微信小程式，支付寶生活號等等。根據需要來吧。

• Node.js是後臺技術，但是放在客戶端，主要為多端資料展示做資料適配等工作。也可以做一下公共邏輯，比如日誌，加解密，統計，以及其他公共業務邏輯。和具體客戶端無關的邏輯放在這裡，只要實現一遍，各種端都能受益。另外，這個主動權掌控在自己手中，不受客戶端是否升級影響，也不會受限制於蘋果稽核機制。更重要的是，客戶端一般處理單頁面單使用者邏輯，而這裡，則不受這兩點限制，發揮空間很大。另外，這裡雖然用後臺的技術，但是要有客戶端的思維，為客戶端開發閉環做好服務。現在JavaScript發展勢頭很猛，在這裡可以很好地發揮一下。

• Node.js閘道器（資料消費者）和Java資料服務（資料生產者）之間，是純粹的資料資訊通訊，不要考慮各種端的差異。比如時間戳，只要一個long資料就可以，不需要考慮是年月日還是時分秒等具體表現形式。這裡基本不需要“文藝青年”的參與，純粹是技術內部“鳥語”。

• 至於是否要引入React Native，weex等，看需要吧。個人認為是不需要。現在蘋果的稽核已經很快了。把隨心所欲升級當做需求是耍流氓。另外，多端一致，全棧工程師，少招幾個開發之類的領導愛聽的話，純粹是損人利己的行為。
  當然，產品、運營一天到晚要搞活動，熱更新，那確實需要H5，如果還要求體驗，React Native，weex也是有一定價值的。面對流氓，也只能耍流氓了。
  真正的動態性，正在的提升效率，將公共邏輯移到Node.js閘道器才是正解。“雲 + 輕客戶端”才是讓企業掌握主動的方式。