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 ${你的專案}

參考：

留言 2 則回應

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總回顧

留言 0 則回應

[讀書心得] 告別瀑布擁抱 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 再說，如此開發人員有個節奏，而不是永遠做不完的死亡行軍。

留言 0 則回應
訂閱： 文章 (Atom)