老生常談得一件事情,如果一個團隊花一個禮拜的時間寫好自動部署的工具,比如用shell,把平常又臭又長或者很繁瑣的指令集結起來,之後這些繁瑣重複的工作就可以透過自動化工具省下不少時間。
表面上看起來或許一年之後你才能把省下來的那幾秒鐘累積成一個禮拜,達成回本的動作,但是如果你不這樣做,你把那一個禮拜的時間打散到一年裡面,換來的就是你一年的開發效率低落。
長遠看來,有沒有做自動化工具的團隊,差距可謂天與地。
知道了自動化的重要性,再來就iOS而言有一套國外Twitter青年才俊高富帥工程師從side project發展成全職開發的iOS自動化工具組-fastlane,國外紅一陣子了,但中文的介紹似乎不多,秉持人飢己飢的精神(?),也方便之後回顧,就來寫這篇吧。
首先我會先請你到官方文件那裡安裝必要的工具,之後我在介紹你tips,讓你可以快速達到自動部署上TestFlight的要求。 當然你之後可以串接Test的流程,確認沒問題了再上TestFlight。
首先到Fastlane的GitHub上依照最新的Installation
章節安裝好Fastlane。接著依照Quick Start
章節的步驟建好初步的文件。這中間可能會問你App ID啦,Apple ID的帳密呀,諸如此類的基礎設定。
接著看到目錄裡面的Fastfile文件,下面文件已經是我改好可以Run的版本,跟初始化的版本會不太一樣,更下面我會介紹是怎麼改過來的:
1 2 3 4 5 6 7 8 9 10 11 |
|
看到lane :beta do
,代表之後我們只要下fastlane beta
就可以指定執行一直到end
包起來的這個區塊的動作。
我們先定義我們的beta要做什麼事情:
1. 把cocoapod裝一次
2. 把build號碼+1
3. 用Production的Provisioning Profiles,build一個ipa出來
4. 把這個版本送到TestFlight上,並送給tester
基本上如果上述都手動的話,大約要花上15分鐘左右(切換Provisioning Profiles, 上傳時間, 還有等iTunes connect處理新版build, 最後再手動送出分發測試版本到tester手上),透過自動化工具可以做到打一行指令後就可以不理了。
上述流程在Fastlane裡面被寫成三行,這三行的設定tips就分三項介紹
increment_build_number
Literally,increment_build_number
就是自動增加build版號,別小看這個功能,以前常常是都發布出去了才發現沒有新增版號!需要配合設定Xcode參數Current Project Version
。參照圖片或這邊。
gym
這是幫我們產生ipa檔案的。後面跟上兩個參數scheme
通常就是你得App名稱,use_legacy_build_api
,則是因為Xcode 7.0的上傳API更改了,所以在使用時有時候會錯,這時候要改用舊的。
pilot
這是幫我們自動部署到TestFlight的,使用時需要加上team_name
參數是因為筆者帳號下有兩個Team,你如果不填上這個Fastlane跑到一半就會問你,這樣自動化就沒意義了。
然後記得搭配pilot時,Xcode要配合在info.plist
加上下面這個屬性:
1 2 |
|
討論串是說iTunes connect建議手動上傳要使用這個參數。相關討論在這個issue頁。
後記
之後可以串接上Slack做完成時的顯示,再更進一步可以搭配Hubot,這樣連fastlane beta
都省了。然後因為沒接觸CI Server,之後也可以研究兩者如何搭配。
其實筆者在用octopress發布文章的時候,明明指令沒幾行也硬是寫了三個shell來發布(new, preview, publish),但實在是幫我省了很多時間,不然每次我可都要去google指令,很煩的。
只能說工程師的懶沒有極限,但正是這種懶造就了人類文明的進步(?)。