引言
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配合。
二、發版流程
- 環境準備
- jdk ：1.8版本以上 （1.8.0_271）
- Maven：儘可能保證3.9版本以上（3.9.6）
- 低版本maven構建部署包會失敗
- gpg：各版本均可 （2.0.22）
- svn：高於1.6版本（1.7.14 ），低版本會報錯
- git：1.8.3.1
- 伺服器系統：MacOS，Linux（Linux伺服器、CentOS7）
- 伺服器要求需要能訪問Apache官網或GitHub，目前Window在同步gpg、公鑰ID時會出現異常，建議儘可能使用非Window系統。
- 發版流程文件
- 中文：
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）gpg安裝
按照文件執行操作
（2）配置maven倉庫
- 修改
settings-security.xml檔案 - 修改
conf/settings.xml配置檔案（注意路徑），檔案中的apache LDAP是apache對應的使用者名稱密碼，明文。
- 依賴包確認
這裡主要檢查依賴包對一個的license 和對應的下載地址。
可以檢視pom的提交日誌，檢視修改記錄，正常在review pr的時候會檢查這一項。但是可能會有遺漏或重複的情況。
- 修改版本
（1）為了方便後續打包等操作，可以增加環境變數。包括後續對svn的一些操作所需的環境變數，建議在文件中新建的變數都建立為環境變數。
（2）文件版本修改
注意：docsdev.js是Apache DolphinScheduler官網該版本的引用位置相關檔案，檔案修改的效果只有在website的pr被merge之後才能體現，所以這部分檔案需要嚴格按照文件修改，建議在打包之前檢查一下檔案的修改情況。
- 部署包構建釋出
部署包的構建分為三個部分
（1）釋出檢查
a.分支準備
首先要在官方的github倉庫建立prepare分支，fetch分支後執行上述命令。文件中的origin要根據使用者clone的倉庫決定，如果直接clone的是官方倉庫，這裡使用origin沒有問題。如果使用的是fork的倉庫，建立upstream（如果叫upstream的話）指向官方倉庫，那GH_REMOTE得是upstream。發版的所有操作都是直接推到官方倉庫。
一般情況prepare分支是基於dev建立的。
在clone或者建立upstream時，最好是使用git協議，不要使用https，否則推送tag會失敗。
b.發版校驗
命令執行大概需要8G記憶體，注意資源。
執行結束後最好檢查一下dolphinscheduler-dist/target資料夾的大小，如果超過950M，並且沒有瘦身策略，發版得暫停。
這一步主要是為了驗證構建部署包的過程是否正確。
（2）發版準備
需要清理掉髮版校驗的檔案，執行clean命令。clean命令執行後可能會存在部分檔案未清理的情況，可以考慮執行git stash暫存。
這裡如果是多次發版，需要再執行 mvn release命令之前清理掉本地和遠端（官方倉庫）的tag，否則會報錯。這裡需要提前配置 注意1 的內容。
該步驟不會有成果。
如果在命令中出現clone prepare分支失敗的問題需要檢查upstream的協議，網路等情況，如果網路不穩定可以重試。
此處需要檢查倉庫中prepare分支和tag的commit，需要一致。
（3）部署釋出
a. 執行命令
該命令基於發版準備的結果，所以【發版準備】的結果不能做任何修改（包括程式碼），命令結束後會在https://repository.apache.org/#stagingRepositories 中顯示內容。這個內容可能會有一點點延遲，但正常不會超過五分鐘。如果發現沒有檔案，大機率是maven的遠端倉庫配置問題，可以排查一下。
如果發版過程中發現有程式碼的修改，需要重新執行發版的操作，必須至少要從【發版準備】開始，執行【發版準備】前需要執行git release:clean 命令，如果有多餘檔案可以git stash暫存。多次發版需要注意stagingRepositories中檔案的時間，如果發現時間與執行發版命令時間不對應情況可能說明包為同步。正常stagingRepositories的檔案會替換，無需主動刪除。
發版過程會使用到gpg -s的命令，命令的密碼快取應該是十分鐘，如果伺服器資源不太夠，構建時間會超過十分鐘，這裡需要保證gpg 密碼的快取時間。
到這裡所有釋出包的構建流程已經結束。
b. 釋出包提交apache倉庫
建議將SVN_DIR_DEV和 SVN_DIR_RELEASE 也都設定為環境變數。
如果是committer這部其實可以不用執行， commit沒有許可權。
這裡DolphinScheduler並沒有開啟對應的設定，所以這部分需要將gpg-key-id匯出來後發給PMC幫忙新增，或者在發版郵件後補充。但是儘可能是新增到KEYS裡面。
這裡需要注意的是tar.gz.asc檔案，可以使用【注意】部分的命令新增，但是在打包的時候其實是已經生成了。也可以手動在maven本地倉庫裡面複製出來。
部分伺服器 shasum的命令沒有，可以使用sha512sum shasum -a 512 = sha512sum.
打包日誌裡面寫了生成的asc檔案位置。
c. 發版檔案檢查
除了上述的檔案，建議在檢查一下`doc/conf/docsdev.js`檔案。
到此為止發版打包的工作就已經結束了。
- 發版郵件
建立RELEASE NODE
這裡要求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. 官網文件修改
如果新增是一個兩個版本號的版本，需要在
https://github.com/apache/dolphinscheduler/blob/dev/.github/ISSUE_TEMPLATE/bug-report.yml中新增對應的版本。比如3.3*這種。
這裡的修改一定要仔細，如果修改錯誤官網就會有內容丟失甚至無法訪問，注意符號的轉義。
pr被merge後，官網的文件就已經可以檢視了，這裡瀏覽器會有快取，清一下，或者無痕開啟。
這裡還需要再發一封郵件，通知發版已經結束。
郵件釋出後需要刪除prepare分支。
- 新聞稿件
新聞稿件主要是描述這次發版的主要變更，一般三位版本號的版本主要修復bug，和一些improvement。稿件中需要簡述一下重點的pr內容，圖片可以檢視pr提交的內容，有的文件中會有對應的圖片，中文文件的pr列表中需要翻譯一下pr的名字。最後的貢獻者在tool中有對應的工具，同樣使用python3.0版本執行。
三、版本驗證
- 官網文件
登入官網檢視對應版本是否正常 - dockerhub映象
不同的服務映象不同，需要檢查所有的映象更新時間和tag
發版完成
恭喜你，完成以上步驟後，Apache DolphinScheduler的發版流程就全部結束了。感謝所有貢獻者的辛勤工作和社群的支援，對發版工作感興趣的朋友可以根據教程實操一下，社群歡迎這樣的嘗試。
本文由 白鯨開源 提供釋出支援！