為了使用flutter，剛開始的時候為了快速上線，採用將flutter和native**混合開發的模式，具體的工程目錄如下：
可以明顯的看到工程目錄很亂，android目錄下有多個**目錄，lib目錄下是dart**，images目錄下是flutter所用到的等資源，而且竟然還包含了ios的**。如此混亂的目錄給我們帶來了四個問題：
需要對native工程進行了大量的改造
為了將flutter整合到native工程裡，對flutter和native的目錄和編譯指令碼都進行了大量的改造，對原來native的工程影響比較大。不開發flutter的同學也必須得配置flutter的sdk
因為flutter的開發需要flutter sdk的環境，但是團隊內並不是所有人都做flutter的開發，如果要求每個人都安裝flutter sdk的環境，無疑帶來了額外的開發成本。無法做持續整合
因為flutter編譯需要flutter的編譯環境，但是現有的持續整合的環境沒有flutter的環境，使得flutter無法做到持續整合。本地編譯環境無法統一
針對上面的問題，我們轉而採用了如下的開發模式：
flutter工程和native工程分開
將flutter和native剝離，flutter是單獨的工程，native也是單獨的工程，這樣從工程上面就將flutter和native徹底分開，兩者互不影響，native工程不在需要改造，單獨開啟native工程也不需要配置flutter sdk的環境。在flutter工程裡編譯flutter的產物，然後整合到native工程裡。本地開發，服務端構建
在本地開發flutter，但是將編譯構建的工作交給服務端來做，因為服務端的flutter sdk的環境是唯一的而且可控的，這樣不管有幾個開發者，本地環境有多複雜，flutter的構建都在服務端，保證了flutter構建產物的一致性。flutter構建產物自動同步
在服務端觸發flutter的編譯，如果編譯成功，會自動將最新的flutter產物同步到native工程裡，保證native的工程裡的flutter產物是穩定的而且是最新的，可以及時看到最新的更改的flutter頁面。這裡持續整合服務是用qci搭建的。
經過以上的改造，工程目錄如下：
可以明顯看到工程目錄清晰了很多，fluttersdk目錄下是flutter的構建產物，對於原來的native工程來說就是乙個module，flutternew目錄下是flutter的業務**，flutternew依賴fluttersdk，flutternew也是native工程的乙個module。經過改造，可以達到如下的效果：
實現flutter對原來native工程的非侵入式整合
flutter只是native工程的乙個module，和其他native的module是平級的，naitvie也不需要關心flutter model的環境，對原來的native工程沒有影響。保證flutter編譯環境的唯一性
因為flutter的編譯都是在服務端進行的，這樣就保證了flutter編譯環境的唯一性，ios和android都是在同乙份**同乙個編譯環境下構建的，也就保證了flutter產物的穩定性。實現了flutter的持續整合
flutter的**提交之後，會自動觸發flutter的構建，可以很容易知道此次的變更是否有問題，最新的flutter構建產物也會自動同步到native的工程裡。經過改進flutter的開發模式，目前已經實現了對flutter的敏捷開發和持續整合,實現了多團隊協作遠端構建產出的模式。
iOS 持續化整合工具
使用過的自動打包工具有jenkins,flow.ci,fastlane 現在同時使用jenkins和fastlane,一本遠端庫,乙個本地庫打包 1.jenkins 配置複雜,歷史要悠久一些,一般工作中使用 穩定版本.單獨配置一台電腦做打包的裝置,可以自定很多東西.功能強大.可以拉取遠端倉庫的不同分...
持續化整合工具 gitlab
1.版本控制系統簡介 版本控制系統是一種記錄活若干個檔案內容變化，以便將來查閱特定版本內容情況的系統記錄檔案的所有歷史變化，隨時可恢復到任何乙個歷史狀態，多人協作開發。安裝 yum y install git root iz0 hhu2rrhmpz git config config file lo...
持續整合 自動化
一 什麼是持續整合 continuous integration 這個名詞已經在軟體開發領域持續了n年，乙個比較簡單的定義如下 持續整合 ci 是一種實踐，可以讓團隊在持續的基礎 上收到反饋並進行改進，不必等到開發周期後期才尋找和修復缺陷。通俗一點兒說，就是指 對於開發人員的每一次 提交，都自動地把...