Pages

Tuesday, October 18, 2011

Version control challenge: 請提供過去問市測試、正式版本的應用程式

*.ipa file
『請提供過去問市測試、正式版本的應用程式給測試人員或是相關人員測試』,根據如此的考題,請問會怎麼做才能做得漂亮,可能需要耗費了點功,但是不置於弄不出來呢,或者是否有問過自己是哪些原因讓身為開發人員的你會使用版本控管來管理程式碼?

以上面的考題用 iOS App 為例,如何取得過去在 App Store 上面的版本,而且可能會有製作方式不同,需要重新的製作出來,例如有切分 Production 或者 Testing 環境的串接。也就是說重新建置 version 1.0 (test / production) 版本、version 1.1 (test/ production)、version 1.2 (test/production) 依此類推可能四到六個不同版本的 App。

如果沒有做版本控管或者說有用版本控管但是沒有用好的方法來管理的話,那麼可能面臨今天這樣考題會做不到了。很慶幸的是,感謝過去這陣子都有養成良好的習慣,加上一些線索推敲,可以讓這個考題解的漂亮。

1. 打開 Xcode 的 Organizer 的 Archives 頁面,這邊詳細記載著過去 Archives 記錄。其中以 Status 欄位為例,Xcode 在交付給 Apple 審核,都會標上 Submitted 記錄,所以整張列表我們可以知道我們曾經給 Apple 送審的記錄。

Organizer - Archives

2. 搭配 Creation Date 我們可以以當天即是重要日,因此帶著時間我們回到版本控管工具上,找出當天大事記的標籤 Tag,可能是 v1.0.11 的紀錄。於是我們找到了時間點與版本記錄。

3. 因為是要時間追逤,所以強烈建議請一定要開新的資料夾,將程式碼可以放到新的環境,不要和原來開發中的資料夾放在一起。以 Git 為例就是到新的資料夾下面再 git clone your-repository

4. 如果 iOS App 有用 Git submodule approach 來做外部 Open Source project 管理,那麼先下 git check 到該 Tag 再來產生 submodule 的建立。原因有一個可能那個時期的 submodule 記錄點跟後來的記錄點不同,所以從那時在建立來還原。如果運氣差一點,submodule 的 URL 已經被取消掉或是不存在,所以意味著一定 Build 不起來了,可能就得找替代方案,所以需要再搭配開設新的 Git Branch 來做找尋新的 submodule 來源調整與記錄修正。如此才能做 git submodule init 與 update。

5. 打開該 Xcode project,進入該版本進行 Build & Run,照道理是要能跑的。開始調整設定檔,因為需要針對該版本製作 (test/production) 等設定後的 *.ipa 檔案。當選擇新的 iOS provisioning profile 再次做好新的 code sign 後,即可 Archive。於是我們在同樣的 Organizer 就可以看到最新一份的 Archive 出爐了。馬上在 Organizer > Archive 針對該紀錄下 Comment 類似 App v1.0.0, Git tag v1.0.11 (test env.) 這樣記錄。

6. 剩下的各種版本設定建置依此程序類推,讓它們一一完成。

以上即可提供過去問市測試、正式版本的應用程式了。過程不是那麼容易,可見平日的各種重要大事紀錄累積是如此的重要。也才能交付這些各種組合版本的熱騰騰的 *.ipa 出去給予安裝。

當我接觸版本控管這幾年開發經驗,從 CVS, Subversion 到今日的 Git 使用經驗,我第一次在心中有如此震撼,碰到如此的挑戰而最終能克服,再回來省思版本控管用好的方法實踐對我們開發人員而言是真的如此的重要。

Sunday, October 16, 2011

TestFlight SDK: Quick, painless integration Instant insight.

https://testflightappcom/sdk/
當我們在 iPhone App 開發之路 一定會有測試階段,不論是功能開發完畢的釋出測試、或者想要搭配使用者測試,如何讓這個過程順利是個很重要一環的活動。在 TestFlight magically distribute iOS Beta testing for your team 說明了讓釋出測試變得如此順利,現在 TestFlight 更進一步推出 SDK 讓我們可以整合到專案裡頭,如果說原來的 Testflight 幫我們做到發佈,現在加入 SDK 可以讓使用者在整個測試過程收集更完整的資料。

一個理想的使用者或者測試人員在使用 TestFlight App 安裝下來的測試版 App,會有哪些情形發生呢?

  • 我們會想要關心使用者測試了多久,有多頻繁地使用。 
  • 我們會想要知道測試過程中有沒有發生 Crash ,這是很嚴重的狀況,一定要能收集到第一手錯誤訊息。 
  • 我們會想要知道不同的測試人員在使用該 App,有通過哪些檢核點,透過群體資料來分析哪些地方還有那些動向測試到呢? 
  • 我們會想知道如果有任何的問題,是否可以透過本身的 App 就提供意見回饋呢?這樣不用另外拿紙筆或者需要額外寫封信,第一時間印象打出資訊送出即可。

Wednesday, October 12, 2011

*.DSYM File Extension

Xcode build setting
這份 Debugging information 檔案是由 Apple 的 Xcode 開發軟體產生的。如果在建置 App 過程當中在 Debugging 階段有選擇 Debug Information Format 設定為 "DWARF with dSYM",這份檔案就會跟包裝檔案裡面。所以如果要找出該放檔案,在 Build 好的 *.xcarchive 檔案,按下右鍵 Show package contents,即可找到 dSYMs 資料夾,裡面就會有 .dSYM 這樣附檔名的檔案。
DWARF 全名是 "Debugging with Attributed Record Formats." 它是由 Xcode 產生出來的 debug 符號,在發佈以前過程中抽離出來,它會儲存了所有 Debug 資訊和產生一份 Debug map。

像我們在 App 發佈測試發生了 Crash 狀況,希望可以解析回來詳細狀況的話,即需要此份檔案。"You can upload a zipped .dSYM for this build to symbolicate your crash reports. " 當類似 TestFlight: iOS beta testing platform 瀏覽詳細狀況時候,會需要開發人員來提供這份檔案。 

Monday, October 10, 2011

TestFlight magically distribute iOS Beta testing for your team

My TestFlight T-Shirt
當我們在 iPhone App 開發之路 一定會有測試階段,不論是功能開發完畢的釋出測試、或者想要搭配使用者測試,如何讓這個過程順利是個很重要一環的活動。很感激的是 TestFlight https://testflightapp.com 讓這一切變得如此簡單和魔術般的神奇。TestFlight 是 Apple 認可 iOS 開發人員可以註冊他們的服務、建立團隊、邀請成員和加入成員們的 iOS 裝置,方便將資訊回到 Apple 的 Provisioning Portal 登記重新包裝新的一份 App,回到 TestFlight 上傳,之後的發佈釋出就是如此的讓整個團隊都能安裝使用,如此的簡單。

對於開發人員 Developer 可以怎麼做?
  1. 從註冊自己帳號,建立自己的團隊。
  2. 開始邀請自己的成員們加入,以方便取得 UDIDs (Unique Device IDentifier)。
  3. 回到 Apple Provisioning Portal 登記,重新建立新的一份 Provisioning Profile 檔案。
  4. 將最新一份 Provisioning Profile 拿來 Code Sign 在該新的 iPhone APplication (.IPA) 檔案。
  5. 回到 TestFlight 上傳該 IPA 檔案之外,填寫 Release Note。
  6. 接著所有需要測試的成員都可以收到通知信,一一安裝在成員的手機裝置上了。

對於測試人員 Tester 可以怎麼做?
  1. 初次使用可能受到邀請函、或者被邀請加入、或者新註冊。
  2. TestFlight 會詢問是否註冊該 iOS 裝置,如此才能讓開發人員取得裝置的 UDID。
  3. 開發人員取得 UDID,重新製作 Provisioning Profile 來包裝建立新的一份 .IPA 檔案。
  4. 等開發人員釋放了,TestFlight 會寄出通知信 email 告知有哪一版可以安裝使用。
  5. 遵循著信件就可以輕鬆安裝該 App。

TestFlight 帶給開發人員的改變是提供了:
  • 完整使用者管理、使用者除了掌握 email 資訊外,也紀錄著裝置的 UDID,方便取得發佈 App 所需要的資訊。
  • 簡單的上傳步驟,方便輸入 Release note,透過 .IPA 檔案解析 Provisioning Profile,讓開發人員可以勾選僅可以發佈的成員名單。這點很重要,因為當開發超過一個 App project,用哪一個 App 可以發佈給那些團隊成員,這邊切割變得要簡單明瞭。
  • 搭配發佈 email 通知到,使用者是否收到信件、開啓信件、點擊信件的 URL link 到最後是否安裝這些的狀態轉換都在平台上有個完善紀錄。

TestFlight 除了完全符合 Apple 開發人員的規範條款之外,又能減少開發人員在測試這個活動上的負擔,讓我們在 App 問市前可以擁有更多機會來測試找出 App 潛在問題。

試著想想看如果今天開發人員和測試人員來自不同公司,而 TestFlight 透過那些功能上的設計,讓跨公司可以合作的如此順利呢?

我們非常感激 TestFlight 這個平台設計的用心與便利性。

Thursday, October 6, 2011

iRate 協助使用者給予我們更多的支持與鼓勵

Rate for Mr. Plurk
iRate 是一套可以協助我們來行銷我們 iPhone, Mac App Store 的 Apps。可以在使用該 App 一陣子後,透過彈出視窗請使用者幫我們評分一下。這樣的提醒可以讓真正有用的使用者來幫我們評分,而且會給予更接近實際的使用心得與推薦。

這套在 GitHub 上面有很多人在維護,而我也先 Fork 一份回來,等未來有時間可以來改善加強它。https://github.com/edwardinubuntu/iRate

不過對於這套的設計,可以幫助我們到什麼樣程度,這是最有興趣的,而在看這套 Library 發現最有趣的是一段 method 叫做 shouldPromptForRating。這也是本套 Library 的核心,該彈出視窗彈出的時機到底為何?透過程式碼可以瞭解到這套彈出時機分為一系列的檢查判斷,並且是有順序性的,分別為:
  1. 是否為 Debug 階段,如果是一定會開啓。
  2. 檢查使用者是否評分過這個版本。
  3. 檢查使用者是否謝絕評分過這個版本。
  4. 檢查使用者是否經過一段時間了,該是請使用者幫忙了。
  5. 檢查使用者開啟關閉該 App 超過幾次,而且使用該 App 有經過些特別的檢核點。
  6. 檢查時間上是否倒了使用者說稍後再提示。
  7. 彈出視窗吧!
所以根據這些條件判斷式,我們可以組合出最適當的設定。彈出的時間點很重要,不要頻繁吵到使用者,也不希望過早還沒摸索清楚就問使用者,又能請使用者給予我們評分提醒,這樣的組合拿捏,確實是一門小小的藝術。