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 使用經驗，我第一次在心中有如此震撼，碰到如此的挑戰而最終能克服，再回來省思版本控管用好的方法實踐對我們開發人員而言是真的如此的重要。