從零到一，全面掌握Apache DolphinScheduler發版流程，實戰派經驗分享！

海豚调度發表於2024-08-21
Apache

file

引言

Apache DolphinScheduler的發版流程對於確保軟體質量和社群協作至關重要，社群Committer王興傑為我們詳細介紹了Apache DolphinScheduler的發版流程，包括環境準備、流程文件、基礎工具準備、依賴包確認等關鍵步驟，並指出了發版流程中可能會遇到的麻煩以及相應的解決方案，歡迎學習指正。

一、發版物料

（1）Apache要求

a. Maven倉庫物料（發版過程中會儲存在臨時庫中）
https://repository.apache.org/content/repositories/orgapachedolphinscheduler-{index}/org/apache/dolphinscheduler/

b. 釋出包、簽名檔案和keys
對釋出版本簽名，使用者也可據此判斷下載的版本是否被篡改。

（2）DolphinScheduler要求
Dockerhub 映象
Helm 檔案

（3）許可權要求

  • PMC Member擁有完整的發版許可權；
  • Committer會有小部分許可權缺失，需要PMC Member配合。

二、發版流程

  1. 環境準備
  • jdk ：1.8版本以上 （1.8.0_271）
  • Maven：儘可能保證3.9版本以上（3.9.6）
  • 低版本maven構建部署包會失敗
  • gpg：各版本均可 （2.0.22）
  • svn：高於1.6版本（1.7.14 ），低版本會報錯

file

  • git：1.8.3.1
  • 伺服器系統：MacOS，Linux（Linux伺服器、CentOS7）
  • 伺服器要求需要能訪問Apache官網或GitHub，目前Window在同步gpg、公鑰ID時會出現異常，建議儘可能使用非Window系統。
  1. 發版流程文件
  • 中文：
    https://github.com/apache/dolphinscheduler/blob/dev/docs/docs/zh/contribute/release.md
  • 英文：
    https://github.com/apache/dolphinscheduler/blob/dev/docs/docs/en/contribute/release.md
  1. 基礎工具準備
    （1）gpg安裝
    按照文件執行操作

file
（2）配置maven倉庫

  • 修改settings-security.xml檔案
  • 修改conf/settings.xml配置檔案（注意路徑），檔案中的apache LDAP是apache對應的使用者名稱密碼，明文。
  1. 依賴包確認
    這裡主要檢查依賴包對一個的license 和對應的下載地址。

file

可以檢視pom的提交日誌，檢視修改記錄，正常在review pr的時候會檢查這一項。但是可能會有遺漏或重複的情況。

  1. 修改版本

（1）為了方便後續打包等操作，可以增加環境變數。包括後續對svn的一些操作所需的環境變數，建議在文件中新建的變數都建立為環境變數。

file

（2）文件版本修改

注意：docsdev.js是Apache DolphinScheduler官網該版本的引用位置相關檔案，檔案修改的效果只有在website的pr被merge之後才能體現，所以這部分檔案需要嚴格按照文件修改，建議在打包之前檢查一下檔案的修改情況。

file

  1. 部署包構建釋出

部署包的構建分為三個部分

（1）釋出檢查

a.分支準備

file

首先要在官方的github倉庫建立prepare分支，fetch分支後執行上述命令。文件中的origin要根據使用者clone的倉庫決定，如果直接clone的是官方倉庫，這裡使用origin沒有問題。如果使用的是fork的倉庫，建立upstream（如果叫upstream的話）指向官方倉庫，那GH_REMOTE得是upstream。發版的所有操作都是直接推到官方倉庫。

一般情況prepare分支是基於dev建立的。
在clone或者建立upstream時，最好是使用git協議，不要使用https，否則推送tag會失敗。

b.發版校驗

命令執行大概需要8G記憶體，注意資源。

file

執行結束後最好檢查一下dolphinscheduler-dist/target資料夾的大小，如果超過950M，並且沒有瘦身策略，發版得暫停。

這一步主要是為了驗證構建部署包的過程是否正確。

（2）發版準備

需要清理掉髮版校驗的檔案，執行clean命令。clean命令執行後可能會存在部分檔案未清理的情況，可以考慮執行git stash暫存。

這裡如果是多次發版，需要再執行 mvn release命令之前清理掉本地和遠端（官方倉庫）的tag，否則會報錯。這裡需要提前配置 注意1 的內容。

該步驟不會有成果。

如果在命令中出現clone prepare分支失敗的問題需要檢查upstream的協議，網路等情況，如果網路不穩定可以重試。

此處需要檢查倉庫中prepare分支和tag的commit，需要一致。

file

（3）部署釋出

 a. 執行命令

該命令基於發版準備的結果，所以【發版準備】的結果不能做任何修改（包括程式碼），命令結束後會在https://repository.apache.org/#stagingRepositories 中顯示內容。這個內容可能會有一點點延遲，但正常不會超過五分鐘。如果發現沒有檔案，大機率是maven的遠端倉庫配置問題，可以排查一下。

file

如果發版過程中發現有程式碼的修改，需要重新執行發版的操作，必須至少要從【發版準備】開始，執行【發版準備】前需要執行git release:clean 命令，如果有多餘檔案可以git stash暫存。多次發版需要注意stagingRepositories中檔案的時間，如果發現時間與執行發版命令時間不對應情況可能說明包為同步。正常stagingRepositories的檔案會替換，無需主動刪除。

發版過程會使用到gpg -s的命令，命令的密碼快取應該是十分鐘，如果伺服器資源不太夠，構建時間會超過十分鐘，這裡需要保證gpg 密碼的快取時間。

file

到這裡所有釋出包的構建流程已經結束。

b. 釋出包提交apache倉庫

file

建議將SVN_DIR_DEV和 SVN_DIR_RELEASE 也都設定為環境變數。

file

如果是committer這部其實可以不用執行， commit沒有許可權。

file

這裡DolphinScheduler並沒有開啟對應的設定，所以這部分需要將gpg-key-id匯出來後發給PMC幫忙新增，或者在發版郵件後補充。但是儘可能是新增到KEYS裡面。

file

這裡需要注意的是tar.gz.asc檔案，可以使用【注意】部分的命令新增，但是在打包的時候其實是已經生成了。也可以手動在maven本地倉庫裡面複製出來。

部分伺服器 shasum的命令沒有，可以使用sha512sum shasum -a 512 = sha512sum.

file

打包日誌裡面寫了生成的asc檔案位置。

c. 發版檔案檢查

file

	除了上述的檔案，建議在檢查一下`doc/conf/docsdev.js`檔案。

到此為止發版打包的工作就已經結束了。
  1. 發版郵件

建立RELEASE NODE

file

這裡要求python要在3.0版本，生成的結果是一個md檔案，檔案中自帶了pr的連結，最好是在檢查一下pr的名稱和對應的位置，這裡的位置錯誤會較多，很多bug也到了improvement裡。

RELEASE NODE建立好後會馬上觸發一個工作流，用來構建docker映象和helm檔案。構建的流水線日誌可以在https://github.com/apache/dolphinscheduler/actions中檢視。

【注意】如果是多次建立RELEASE NODE的話，需要檢查一下
https://github.com/apache/dolphinscheduler/releases是不是有重複的內容，或者先把原來的刪掉再建立新的。這裡新建立的不會覆蓋，只會新增。

郵件一共有三封

a. 發版投票郵件
按照指導文件中的內容編寫郵件即可，傳送郵件的郵箱需要提前訂閱dev郵件，否則其他人回覆的郵件無法看到。

郵件寫完後再次檢查一下里面涉及到所有的連結，是否有正確的內容。

等待72小時以上，至少有三名pmc參與投票，committer和contributor不要求數量。沒有一名PMC發出-1的投票，則投票結束。

b.投票結束郵件
按照指導文件中的內容編寫郵件即可，投票人員的title需要問社群，以前官網有pmc和committer的名單，但是最近找不到了。

c.第三封郵件在後續內容介紹

8. 官網文件修改

file

如果新增是一個兩個版本號的版本，需要在
https://github.com/apache/dolphinscheduler/blob/dev/.github/ISSUE_TEMPLATE/bug-report.yml中新增對應的版本。比如3.3*這種。

這裡的修改一定要仔細，如果修改錯誤官網就會有內容丟失甚至無法訪問，注意符號的轉義。

pr被merge後，官網的文件就已經可以檢視了，這裡瀏覽器會有快取，清一下，或者無痕開啟。

這裡還需要再發一封郵件，通知發版已經結束。

郵件釋出後需要刪除prepare分支。

  1. 新聞稿件

新聞稿件主要是描述這次發版的主要變更，一般三位版本號的版本主要修復bug，和一些improvement。稿件中需要簡述一下重點的pr內容，圖片可以檢視pr提交的內容，有的文件中會有對應的圖片，中文文件的pr列表中需要翻譯一下pr的名字。最後的貢獻者在tool中有對應的工具，同樣使用python3.0版本執行。

三、版本驗證

  1. 官網文件
    登入官網檢視對應版本是否正常
  2. dockerhub映象
    不同的服務映象不同，需要檢查所有的映象更新時間和tag

file

發版完成

恭喜你，完成以上步驟後，Apache DolphinScheduler的發版流程就全部結束了。感謝所有貢獻者的辛勤工作和社群的支援，對發版工作感興趣的朋友可以根據教程實操一下，社群歡迎這樣的嘗試。

本文由 白鯨開源 提供釋出支援！

相關文章