ci腳本
1. 基於K8s的CI/CD系統
基於k8s搭建的一套CI/CD系統，其目的是方便k8s和服務端相關技術的實踐，在搭建過程中會涉及docker、dockerhub、k8s、github、jenkins、kubesphere
一台Mac物理機+3台Centos虛擬機
Docker是這個教程的基石，對Docker一點都不了解的同學，建議去B站看一下我發布的 Docker小白快速入門+實戰 ，課程比較簡潔，主要幫助不了解Docker的同學快速掌握並應用
安裝命令如下
k8s是一個容器編排工具，可以輕松實現應用的擴/縮容、集群等，具體安裝方式參考文檔我的 k8s集群安裝
這是k8s的一個web管理界面，用於簡化k8s的操作。
在k8s繼續的所有節點上都需要安裝nfs-utils、rpcbind，搭建步驟參考我的 Centos7搭建NFS服務端
kubesphere明確說明基於k8s安裝需要配置DefaultStorageclass，創建步驟參考我的 k8s基於NFS創建Storageclass
安裝時間會有一點長，安裝步驟參考我的 k8s集群安裝Kubersphere
jenkins在這里是作為一個紐帶的作用，因為jenkins在構建項目時可以執行shell腳本，因此通過shell腳本輕松的將github、docker注冊伺服器、k8s集群三者關聯起來，從而簡化jenkins的使用（就是一個偏運維的工具而已）
這里之所以使用Docker安裝Jenkins，是因為我不想在物理機上安裝jenkins（畢竟只是一個工具），而虛擬機已經啟動了三台，再創建就會影響我的物理機性能，所以這里直接使用物理機的Docker跑Jenkins，用完就刪了。
安裝步驟參考我的 基於Docker安裝Jenkins
免密訪問k8s集群的master伺服器
參考我的 Linux配置免密登錄 ，這里需要進入jenkins容器內部進行操作
配置github的ssh key訪問
在jenkins創建一個自由風格的軟體->填寫倉庫地址->編寫如下腳本
一個簡單的CI/CD系統就搭建完成了，後面可以把更多的重心放在k8s資源文件的編寫上，理解yaml中各節點的含義也是一項不小的工作量，搞清楚k8s的各個模塊，對服務端的架構設計是有益的。
2. Gitlab-CI自動化打包之Runner配置和CI腳本說明
在gitlab上新建一個打包工程目錄，比如auto_build_game_apk( https://gitlab.com/CocosTool/auto_build_game_apk )，必須獲取工程的master許可權。
示例Cocos Hello World工程: https://gitlab.com/CocosTool/cocos_example
新建腳本文件.gitlab-ci.yml:
3. 自動化測試如何和ci系統集成
CI和自動化先天是分不開的
一般的CI系統都會支持JOB，job一般都可以調用命令行、shell、腳本等等。自動化測試腳本通過job運行起來，再把測試結果按照CI系統的要求吐回測試報告（一般如Junit測試報告），則整個過程就集成了。自動化測試的job一般會再版本構建完成，測試環境初始化完成這些job完成後自動觸發或定時觸發
4. CI/CD的實踐
阿里雲的 Docker 鏡像源添加
docker服務基本的操作
得到密鑰後填入，繼續
然後再點擊去安裝推薦插件
docker 的架構是 C/S 架構。在我們使用 docker 命令時，其實是命令使用 socket 與 docker 的守護進程進行通信，我們需要將jenkins添加到docker的用戶組,才能正常執行 docker 命令
NODE
伺服器上生成
把公鑰添加在到git, 私鑰添加到jenkins源碼管理
本地文件添加DockerFile和nginx配置
構建腳本
然後構建生成一個新的鏡像
鏡像庫就是集中存放鏡像的一個文件服務。鏡像庫在 CI/CD 中，又稱 製品庫 。構建後的產物稱為製品，製品則要放到製品庫做中轉和版本管理。常用平台有Nexus，Jfrog，Harbor或其他對象存儲平台
5. 如何一步步實現AndroidCI
一步步實現Android CI
Android上的CI構建鏈與其它平台一致，依然包含Compilation, Testing, Inspection,
Deploying階段，每一個階段的Feedback的都保持對整個團隊透明。
2、添加Function Test
Android為大家提供了一套集成測試框架Android integration testing
framework。但此框架未集成Cucumber，這導致每增加一個Function Test都需要較大的開發和維護工作。這樣高成本的實現Function
Test將大大延緩開發進度，最終因為項目進度的原因導致Function Test被丟棄。產生這樣的後果那必然是不願意看到的。
目前Android平台下已經出現多種Functiong Testing測試工具，如Native Driver, Robotium,
Calabash等。在嘗試對比後，最終選擇了Calabash Android作為解決方案。Calabash
Android是Cucumber在Android平台的實現，使用Ruby書寫Function Test，並提供了一組操作Anadroid App元素的API。
3、添加UI Test
Android在新近退出了UI測試工具UIAutomator。此工具僅支持Android4.1及以上平台，鑒於目前市場上2.3和4.0版本仍佔主導的情況來看，目前還無法滿足大家的需要。另外應用該工具實現UI測試的開發成本還較高，筆者暫不推薦使用此工具，但應該關注其發展。
另外基於錄制回放機制的測試方法同樣可以進行UI測試。但錄制回放的方法在面對功能快速迭代時，維護工作會急劇增加，而這個維護成本可以說是很難承受的，所以在此也不會將這種測試方法集成至CI中。
目前來看Android中UI測試還無令人滿意的方法。若對UI成功比較看重，可以投入精力應用UIAutomator進行UI測試。
Best Practice:
*
將測試按照單元測試，組件測試，功能測試和系統測試進行劃分。單元測試應該在每次提交時觸發執行，其它的測試根據運行時間長短和重要程度可以每次提交觸發執行或者定時周期執行。
* 將運行較快的測試優先執行。
* 讓功能測試能夠重復執行。否則維護成本太高，會被舍棄。若是後台數據導致不可重復，可以將數據抽象成為數據集，在每次運行前進行重置。
* 書寫測試時每一個assert只做一種判斷，這樣可以明確每次測試的目的，並且可以快速定位測試失敗願意。
步驟 3：持續檢查持續檢查是對於代碼本身檢測和反饋。檢測主要通過對代碼靜態分析驗證代碼風格，編程規范，代碼復用，代碼語言中的Best Practice等多個維度的代碼質量。
Sonar作為一個開源的代碼質量檢測工具，涵蓋了7項代碼質量檢測方式。這充分滿足Android平台下對於代碼質量的檢測分析。Sonar分為兩部分一部分是代碼分析工具，另一部分是數據分析展示的Server。
Best Practice:
* 將測試覆蓋率，代碼分析結果透明化
* 持續降低代碼復雜度
* 持續的促進設計的演進
* 持續的維護代碼結構
* 持續減少代碼重復
步驟 4：持續部署
由於Android App採用用戶手動從Appstore自行下載安裝的方式發布，使得Android
App無法直接部署至用戶手機中。另外Appstore需要對於上線的App進行審核，不能持續進行Release。因而Android中持續部署將以持續發布可安裝包為目標。
在以上目的下，只需根據自身項目資源找到合適的安裝包管理工具即可。如本文採用Dropbox來管理所有安裝包。
Dropbox作為一個雲存儲平台，在Android終端設備上可以輕松下載存放在其中的文件，同時上傳安裝包也可以交由Dropbox自己完成。
步驟 5：持續反饋
反饋是所有改進的開始，必須要讓所有人獲取到他們所關心的反饋信息，才能實施改進。持續反饋的目的就是讓所有人都掌握項目健康狀況。項目所有人事實都是有意願知道項目當前的健康狀況的，那CI就應該將項目的情況做到透明，並將不同的反饋通知到各相關的成員。
CI不同階段產生了不同維度的反饋，如單元測試報告，測試覆蓋率等。本實踐中將這些反饋都透明的展示在項目首頁中。之所以沒有將這些反饋再以郵件的方式通知所有人，是因為團隊成員已經養成了查看CI的習慣。
如果說只給所有人發一封郵件說明項目狀況，那必然是告訴所有人「CI所有步驟是否都返回正確？」。這樣一個反饋，包含了編譯正確，所有測試通過，安裝包已經准備完畢等重要信息。有必要讓所有人都知道這個信息，特別是在CI執行失敗的時候。Jenkins自身已經提供一個簡單有效的透明化方法，以項目為藍色表示通過，紅色表示有步驟失敗。
反饋的通知方式有很多種，不一定要採用郵件通知的方式。可以尋找更加有趣的方式，如果播放音樂和設置警報燈。在每一次Build成功或失敗後都播放一段有趣的音樂，打開不同顏色的警報燈，這兩種方法都是是一種簡單有效的方式，可以讓項目所有人都獲取到最為關鍵的信息。
6. CI中的腳本怎麼在Linux下定時運行
Linux中，周期執行的任務一般由cron這個守護進程來處理 ps -ef | grep cron cron讀取一個或多個配置文件，這些配置文件中包含了命令行及其調用時間。 cron的配置文件稱為「crontab」，是「cron table」的簡寫。