欧美vvv,亚洲第一成人在线,亚洲成人欧美日韩在线观看,日本猛少妇猛色XXXXX猛叫

4、CI/CD 平臺遷移實踐：從 -CI 轉移到

最近，因為 屢屢部署出錯，而我們的賬戶因為使用的較多，已經超出了免費使用的限制，以此為契機，將 CI 從 CI 遷移到 。

項目介紹

是 LCTT 翻譯組的主要協作項目，幾百位譯者通過 進行圍繞開源、Linux、軟件工程等領域的文章翻譯，從 2013 年來，累計了大量的提交，致使項目下有非常多的文件。

借助于 CI 幫助譯者對基本的文章格式和拉取請求進行檢查；并定時執行命令，以進行所有的申請檢查，對于超時未完成翻譯的工作進行回收；對于文章的狀態進行標記，生成相應的徽章。

遷移思路

CI 和 在使用方面，其實總體差異不會太大，都是基于 YAML 文件格式來編寫配置文件。不過，和 CI 不同的是， 支持多個不同的配置文件，因此，你可以根據不同的場景，設定不同的配置文件，降低單個配置的文件的復雜度。

此外，由于我們的腳本中依賴了一些 CI 的環境變量，也需要將其替換為 中的相應環境變量，從而確保腳本可以運轉。

改造實踐

1. 分析之前的 CI 流程

我們在 上的 CI 配置文件如圖

總體可以分為三塊：

命令區：說明了安裝階段和執行階段的操作有哪些條件區：指定了這個配置文件在哪些條件下會生效部署區：寫明了構建產物如何進行部署

在命令區中，有預置的安裝過程和后續的執行過程。在安裝過程中，安裝了一些依賴，并將當前的 pages 資源克隆到本地，以繼承上一次構建生成的資料。在條件區則指明了僅作用于分支

在部署區便是將前面命令區的執行結果進行部署。

在實際的執行過程中，還會根據環境變量不同，決定是否要執行特定的命令，這部分在后續的改造過程中，就可以調整部署，拆分到不同的文件中。

2. 直接套用配置文件

在完成了基本的分析后，就可以建立新的 配置文件了。由于基本的語法很類似，對于其中的不少內容可以進行直接套用。

比如，我們的配置文件在直接套用后，結果如下

直接套用的文件已經可以直接運行，不過，這里有很多不滿足需要的地方，所以需要做一些修改。

3. 恢復 CI 的環境變量

由于我們使用的 Badge 等生成腳本并非我所編寫，所以在這一次的遷移中，并不打算對齊進行調整，以避免出現故障。而腳本中依賴了一些變量，需要將其重新設置出來。

提供了一些方法，可以讓你手動設置環境變量。你可以在你的構建的步驟中，加入如下代碼，從而在構建環境中設定 和 環境變量，確保你可以使用這個環境變量。

cing: 0.544px;">
?-?name:?Set?ENV?variables
????????run:?|
??????????echo?"::set-env?name=TRAVIS_BRANCH::${TRAVIS_BRANCH:-$(echo?$GITHUB_REF?|?awk?'BEGIN?{?FS?=?"/"?}?;?{?print?$3?}')}"?
??????????echo?"::set-env?name=TRAVIS_EVENT_TYPE::$(if?[?"schedule"?==?"${{?github.event_name?}}"?];?then?echo?"cron";?else?echo?"${{?github.event_name?}}";?fi)"


此外，由于 set-env 這個方法相對比較危險，你還需要在環境變量中，開啟危險函數的執行。
jobs:
??build:
????runs-on:?ubuntu-latest
????env:
??????ACTIONS_ALLOW_UNSECURE_COMMANDS:?true

4. 拆分配置文件

  和  不同的一點是你可以將你的 CI 文件拆分成多個文件，從而降低每一個單獨的配置文件的復雜度。
根據前面對于流程的分析，可以將我們的 CI 流程拆分成三個部分：
生成badge文件，應當跟隨每一次提交進行生成文件，執行時間較長，可以定期執行根據拉取請求內容進行整理，做核驗
則將我們的配置文件拆分成三個不同的文件：
也得益于拆分開，則在  中就可以免于安裝一些必要的依賴，從而精簡 CI 流程，提升 CI 的執行時間。
5. 測試 CI 的運行情況
在完成了配置文件的編寫和拆分后，就可以進行本地的執行測試。  寫完了頁面加載完成后執行多個函數，難免要執行一下，確保整個流程是正常的。
這個時候你可以安裝工具（），來在本地執行  ，從而確認你的代碼執行是正確的。
如果你是 macOS ，只需要執行 brew  act 就可以安裝 act 工具，來完成 act 的安裝。

安裝完成act，就可以通過執行act命令來在本地執行  ，比如，執行act 來觸發  的拉取請求事件
通過本地測試后，再將你的配置文件推送到  上，進行生產環境的測試即可。
6. 移除 -CI
通過上述的一些步驟，我們完成了從  CI 到   的遷移，此時，就可以移除項目根目錄中的 ..yml 文件，徹底關閉  CI。
7. 替換環境變量
在完成了基本的遷移后，需要對代碼中的一些歷史問題進行修復。在第三步中，我們對于 -CI 的環境變量進行替換，但長期維護的項目應當盡量將這些未標注上下文的信息替換為有文檔標注的，因此，我們需要將其替換。
替換環境變量主要依賴  官方的環境變量說明，你可以參考官方文檔。
簡化后，配置文件從之前的 27 行，減少至 17 行，變得更加的精簡、易懂。
8. 修改  的分支保護條件

為了確保修改符合標準，我們限制了新的拉取請求必須通過 CI 檢查，才能合并進入  分支，因此，也需要修改相應的分支保護規則，確保設定相應的保護。
一些注意事項
1. 環境變量不同
如果你依賴了環境變量，則需要進行相應的修改?；蛘呖梢韵裎乙粯?，先通過 set-env 來讓本地擁有臨時的環境變量，后續再逐步進行遷移。
2.  運行依賴要注意安全
 執行過程中會有兩個部分。 本身流程依賴于  分支，但執行過程中調用的腳本是根據源決定的，因此，從安全角度來看，你應當盡可能將所有的流程放在  中，而不是放在你的源碼目錄中。
3. 如何觸發 CI 的 Pull  檢查？
在進行 Pull  測試的時候，需要不斷觸發不同的  ，你可以通過執行 git  --allow-empty -m " " && git push 來觸發一個空白的 ， 推送到  后，就可以再次觸發 pull  的構建頁面加載完成后執行多個函數，提升構建的效率。
總結
通過對  的流程整理、代碼修改等流程，我們將之前的 -CI 遷移至速度更快、性能更好的   ，一方面可以優化我們的工作流，另一方面，也讓我們的代碼更加簡潔明了。
對于還在使用  CI 的項目來說，也可以考慮遷移到   中，來優化自己的工作流。