Build Android apk 流程

最快產生 apk 的方式當然是用 IDE 匯出就好,但因為我要用客製化的 android.jar 來編譯,還要讓 jenkins Server 能自己 build apk,所以必須要了解 build apk 的流程。

在 Andoid 專案下看到 build.xml 那就八九不離十是用 ants 來做這件事,點進去看大概的思考邏輯就是:

  • 會 import Android SDK 的 build.xml,檔案位置會在 ${android_sdk}/tools/ant/build.xml
  • 可以利用 ant 命令列帶參數覆寫 property
  • 可以建立 ${你的專案}/ant.properties 來覆寫 property
  • 覆寫 Android SDK 的 build.xml 裏的 target
  • 新增 Android SDK 的 build.xml 裏的 target
到 ${android_sdk}/tools/ant/build.xml 最下面可以看到定義好的所有 target,很明顯要包 apk 需要執行 release 這個 target,執行成功可以看到以下 target 被執行的過程為:
  1. -set-mode-check:
  2. -set-release-mode:
  3. -release-obfuscation-check:
  4. -pre-build:
  5. -check-env:
  6. -setup:
  7. -build-setup:
  8. -code-gen:
  9. -pre-compile:
  10. -compile:
  11. -post-compile:
  12. -obfuscate:
  13. -dex:
  14. -crunch:
  15. -package-resources:
  16. -package:
  17. -post-package:
  18. -release-prompt-for-password:
  19. -release-nosign:
  20. -release-sign:
  21. -post-build:
  22. release
這些都搞定之後,就可以根據自己的需求來 修改 property 或是 覆寫 target,這裏才是地獄的開始,Good Luck!

PS:利用指令自動產生專案跟 ants 相關的檔案 > android update project -p ${你的專案}

參考:

Jenkins 兩個月心得

寫一下這一兩個月使用 Jenkins Server 的心得,我目前使用的狀況如下:

  • Android APP 專案 * 1
    • 自動定期查詢 SVN Server,若有更新就開始建構流程。
    • 在 Jenkins Server 上安裝 Android SDK,搭配 Android 產生出來的 build.xml 建構 APK。
    • 搭配 ANTS 用廠商提供的 jar 簽署 APK。
    • 封存最終的 APK(只保留最新10筆),可直接從 Jenkins Server 上下載。
  • ASP.Net 專案 * 1
    • 手動去 SVN Server 抓 Code,開始建構流程。
    • 搭配 Linux Script 針對測試環境 / 正式環境去改關鍵設定檔內容。
    • 將 Project 排除掉不需要的資料夾(.git, .svn ...etc)打包成 zip 檔。
    • 將 Project / zip 檔上傳至測試環境 / 正式環境。
  • Java SE 專案 * 1
    • 自動定期查詢 git Server,若有更新就開始建構流程。
    • 在 Jenkins Server 上專裝 Java SDK,搭配 ANTS 產生 jar 檔。
    • 封存最終的 jar 檔(只保留最新10筆),可直接從 Jenkins Server 上下載。
螢幕快照 2015-01-27 下午12.25.21

流水線的建置

基本上所有行為都還是要 Jenkins Server 要先安裝好工具,再找 Jenkins 上有無別人開發好的 Plug-in 去介接這些工具,簡化設定流程。真的都沒有才會考慮用 linux / windows command 的方式去接。

比如要導入 Selenium 進行瀏覽器做自動化測試,那 CI Server 就要先安裝 Selenium 和 Firefox 等,像我目前的 CI Server 只是一台沒有 GUI Shell 的 Linux ,想要用 Selenium 就 GG 了!

方便

一鍵產出檔案,然後網頁上就可以直接下載。我就不用自己包好然後才 mail 寄給大家,之後還要考慮到其他人到底是用哪個版本的問題,直接就丟 URL 請對方下載就好!

一鍵就發佈網站。明明只是改幾行,但部署到主機上有很多眉眉角角(主機位址帳號密碼,哪些檔案不能覆蓋...etc),一定要翻文件才能一步步做,現在一鍵就完成了,若發佈有問題,馬上拉上一版的 Code 一鍵 rollback。

目前這台 Jenkins Server 也只是台 VM,VM 備份出來在其他實體機器上還原就又可以 build code 了,接手的人只要會改 Code 會上版本控管就夠了,這可比寫文件來得實用多了。

陣痛期

痛的點大概就是:

先搞懂什麼是 CI > 搞懂 Jenkins 怎麼使用 > 搞懂 Jenkins 可以做哪些事情 > 搞懂各種專案怎麼建置

考量到現在 IDE 太強大了,很多人(包括我)都只會利用 IDE 產出檔案。但導 Jenkins 就必須要自己跳下來弄懂 Build Code Command,流程和背後的原理,這的確是有心要精進自己軟體開發能力的人不得不去碰的,要不然就會被 IDE 綁定,明明都是 Java Web 專案卻只能用 NetBean 某一版開發?

此外,你做出來的成果是可以被重用的,因為 Jenkins 也不過就是台會做事的主機,而且提供 Web 介面,其他人只要上去按的鈕就開始跑了。這樣的改變,比你拿一個 build.xml 讓其他人去用來的讓人接受...

目前結論

如果你已經有了自己的建構流程(ANTS,Grandle,Script...etc),可以重新把這些東西整合進 Jenkins,其他人也就在不知不覺中用到這些成果。如果你連自動化建構還不了解,那還是先從寫寫 ANTS 開始。

以 Java 來說,寫桌面程式就包一個 jar,寫網頁程式不就包一個 war 然後 FTP 上傳,寫 Android APP 就包一個 apk,初期沒有要導 unit test,code style 檢查這些東西,其實要弄懂的東西也就是如何擺脫 IDE 自己包檔案出來罷了,對很多以前 筆記本 + 命令列 的前輩應該都是一片蛋糕。

對於團隊來說,至少我覺得導入 CI Tool 會減少人員請假或是離職交接所帶來的衝擊。再來考慮到補上單元測試,整合測試,程式碼風格檢查這些東西,能夠大大增加專案發佈的信心和品質。


參考:CI Server 30 - Jenkins總回顧

[讀書心得] 告別瀑布擁抱 Scrum



原本想自己畫一張圖來說明,不過網路上已經看到很棒又很宅的說明圖,就直接引用了。

先說明一下角色:

  • Product Owner:就是 PM,客戶需求與開發團隊的橋樑,確認做出來的東西是不是客戶想要的。
  • Scrum Master:熟悉 scrum 的人,了解 scrume 流程要做些什麼,有哪些 scrume 工具(ex:看板,燃盡圖...etc)可以用。
  • Team:就是實際在開發的開發成員啦。
接下來就直接看圖說故事了。


圖片來源:http://www.scrumprimer.org/en/anime

整個流程可以分成三大塊:
  • Sprint 計畫會議(上圖左)
    • 類似 kick-off 會議,Product Owner 將客戶需求說明給大家聽,由開發成員把需求轉化成工作清單。
    • 決定第一個 Spirit 的工作清單。
    • 會議時間不超過一天。
  • 每個 Sprint(上圖中)
    • 一個 Sprint 為一週 ~ 一個月。
    • 每個 Sprint 的目標就是完成該 Sprint 的工作清單。
    • 每日立會
      • 昨日完成哪些工作。
      • 今日預計要完成哪些工作。
      • 讓別人知道遇到那些困難,會後就可以討論。
      • 每日立會時間不超過15分鐘。
    • Product Owner 要保證不變動目前在開發的需求,所有變動都等到這個 Sprint 完再說。
  • 每個 Sprint 結束後(上圖右)
    • 檢視會議
      • 檢視目前的專案狀況。
        • 完成的工作。
        • 沒完成的工作。
        • 新增加的需求。
      • 決定下個 Sprint 的工作清單。
      • 決定是否要繼續執行專案。
    • 回顧會議
      • 針對開發流程做討論。
      • 預估 SKD 是否準確,為什麼?
      • 哪些流程工具需要改進。
    • 兩個會議時間加起來不超過一天。
最直白來說,不斷執行 Sprint,執行完一個 Sprint 就做調整。

個人感覺最大優點有幾個:
  • 理論上每個 Sprint 完,都應該有個可以動的東西(雖然功能可能不足)讓客戶看到並反饋,再根據客戶反饋來修正或修改需求,而不用等到第一次正式交付才發現我做的不是你要的。
  • 開發成員眼前的目標就是這個 Sprint 的工作,而 PM 要保證這個 Sprint 內都不會有變動也沒人會去打擾開發成員。有變動沒關係,下個 Sprint 再說,如此開發人員有個節奏,而不是永遠做不完的死亡行軍。