企业官网建设流程全解析

• 机器学习
• 后端
• 大数据

导读

本文以 Apache PredictionIO 项目仓库根目录下的 PMC.md（Project Management Committee Documentation，项目管理委员会文档）为主体，完整讲解一个 PMC 成员从准备代码签名密钥、创建发布分支、打包签名、Maven 制品发布、社区投票到最终正式发布并发出公告的 27 步全流程。读者读完将掌握 Apache 开源项目的标准发布工程实践，并理解每一步与 PredictionIO 仓库内 make-distribution.sh、build.sbt、KEYS、RELEASE.md 等文件之间的对应关系，可直接用于实际操作或作为自建项目发布流水线的参考模板。

一、文档定位：什么是 PMC 发布流程

PMC.md 是一份面向Apache PredictionIO 项目管理委员会（PMC）成员的发布操作手册，其核心目标只有一个：创建一个新的官方版本（Release）。它不讨论引擎开发、事件服务器配置等产品功能，而是聚焦于 Apache 软件基金会（ASF）所要求的、围绕"发布候选（Release Candidate，RC）→ 社区投票 → 正式发布"的一整套工程与治理流程。

整个流程可以归纳为三个阶段：

后续章节将严格按这 27 个步骤展开，并在关键节点结合仓库源码补充底层实现细节。

二、发布前置准备：签名密钥与 KEYS 文件（步骤 1–2）

2.1 生成代码签名密钥

发布的第一步是为 Apache 项目生成专用的代码签名密钥（Code Signing Key）。文档要求参照 Apache 官方的 OpenPGP 密钥生成指南（apache.org/dev/openpgp.html#generate-key）生成强密钥。这一步不能省略，因为后续所有发布产物（tarball、Maven 制品）都必须携带 GPG 签名，供投票者和用户验证来源与完整性。

2.2 将公钥追加到 KEYS 文件

生成密钥后，需要把自己的公钥追加到源码树根目录的KEYS文件中。仓库根目录下确实存在 KEYS 文件，其头部注释明确说明了开发者追加公钥的规范命令：

pgp -kxa <your name> and append it to this file. (pgpk -ll <your name> && pgpk -xa <your name>) >> this file. (gpg --list-sigs <your name> && gpg --armor --export <your name>) >> this file.

文件中已收录多位 Apache 提交者的 PGP 公钥块（如4096R/D3541808 Suneel Marthi (CODE SIGNING KEY)等），这正是历史上历任发布者累积的签名密钥记录。普通用户验证发布产物时同样使用该文件：

gpg --import KEYS

三、创建发布分支、版本号提升与 CI 验证（步骤 3–5）

3.1 创建 release 分支并替换 SNAPSHOT 版本号

文档给出的操作序列如下：

git checkout -b release/0.15.0 # 将代码树中所有 0.15.0-SNAPSHOT 替换为 0.15.0 git commit -am "Prepare 0.15.0-rc1" git tag -am "Apache PredictionIO 0.15.0-rc1" v0.15.0-rc1

在 PredictionIO 仓库中，版本号只在一处集中定义：根目录 build.sbt 的第 40 行：

version in ThisBuild := "0.15.0-SNAPSHOT"

因此"替换所有 SNAPSHOT"实际就是把这个统一入口从0.15.0-SNAPSHOT改为0.15.0，随后提交并打上带注释（-a）的 RC 标签。标签格式约定为v<版本>-rc<编号>，例如v0.15.0-rc1。

3.2 推送分支与标签

git push origin release/0.15.0 git push origin v0.15.0-rc1

3.3 等待 Travis CI 通过

推送后需要等待 CI 在 release 分支上通过构建。仓库中的 .travis.yml 给出了当时的构建矩阵，共包含多组环境：

• BUILD_TYPE=Unit+ 全部数据存储为 PGSQL 的单元测试；
• BUILD_TYPE=Integration+ Elasticsearch 6.8.1 元数据 / S3 模型数据 的集成测试；
• BUILD_TYPE=Integration+ Elasticsearch / HBase 1.2.6 / LocalFS 的集成测试；
• BUILD_TYPE=Integration+ PostgreSQL + Spark 2.0.2（Scala 2.11.12）等。

也就是说，RC 分支必须在这组涵盖单元与集成测试的矩阵上全部绿，才具备进入打包阶段的资格。

四、源码发布候选（RC）的打包、签名与校验（步骤 6–8）

4.1 用 git archive 生成干净源码包

为了确保发布包是从版本库干净导出（不含本地未提交改动），文档使用git archive而非直接拷贝工作目录：

git archive --format tar v0.15.0-rc1 > ../apache-predictionio-0.15.0-rc1.tar cd ..; gzip apache-predictionio-0.15.0-rc1.tar

4.2 生成 detached 签名

对压缩后的源码包生成分离式 GPG 签名（.asc文件与包分离存放，便于验证）：

gpg --armor --output apache-predictionio-0.15.0-rc1.tar.gz.asc \ --detach-sig apache-predictionio-0.15.0-rc1.tar.gz

4.3 生成 SHA512 校验和

使用gpg自带的摘要能力输出 SHA512 校验文件：

gpg --print-md SHA512 apache-predictionio-0.15.0-rc1.tar.gz \ > apache-predictionio-0.15.0-rc1.tar.gz.sha512

这样每个 RC 产物都同时具备"签名（验来源）"与"校验和（验完整性）"两道保障。

五、二进制发行版构建：make-distribution.sh 剖析（步骤 9）

源码包之外，PredictionIO 还会发布开箱即用的二进制发行版。文档第 9 步指示运行根目录的./make-distribution.sh，然后对生成的二进制包重复步骤 6–8（改名、签名、校验和）：

mv PredictionIO-0.15.0.tar.gz apache-predictionio-0.15.0-bin.tar.gz gpg --armor --output apache-predictionio-0.15.0-bin.tar.gz.asc \ --detach-sig apache-predictionio-0.15.0-bin.tar.gz gpg --print-md SHA512 apache-predictionio-0.15.0-bin.tar.gz \ > apache-predictionio-0.15.0-bin.tar.gz.sha512

make-distribution.sh 的源码揭示了该脚本的完整行为：

1. 参数解析（第 22–59 行）：支持-h/--help、透传-D*JVM 属性、以及可选的--with-rpm与--with-deb开关，分别对应 assembly/build.sbt 中启用的RpmPlugin与DebianPlugin打包目标。

2. 版本号自动提取（第 64 行）：从build.sbt的version in ThisBuild中正则提取当前版本（0.15.0-SNAPSHOT场景下输出对应构建版本），无需手工指定。

3. 构建任务链（第 70–73 行）：

   sbt/sbt "${JAVA_PROPS[@]}" clean sbt/sbt "${JAVA_PROPS[@]}" printBuildInfo sbt/sbt "${JAVA_PROPS[@]}" publishLocal assembly storage/publishLocal storage/assembly sbt/sbt "${JAVA_PROPS[@]}" assembly/clean assembly/universal:packageBin assembly/universal:packageZipTarball

   其中printBuildInfo是 project/PIOBuild.scala 定义的 task，在根 build.sbt 中实现，输出PIO_SCALA_VERSION、PIO_SPARK_VERSION、PIO_HADOOP_VERSION、PIO_ELASTICSEARCH_VERSION、PIO_HBASE_VERSION等构建环境信息。

4. 组装 dist 目录（第 84–106 行）：创建bin/、conf/、python/、lib/（含lib/spark）、project/、sbt/目录，把仓库的bin、conf、python、assembly产物、project/build.properties、sbt/sbt启动器拷贝进去，并做两处关键处理：

   • 移除lib/下的*javadoc.jar与*sources.jar，控制发行体积；
   • 将pio-env.sh.template重命名为pio-env.sh（conf/pio-env.sh.template），作为用户后续定制的入口。

5. 产出 tar.gz（第 108–121 行）：最终生成PredictionIO-<VERSION>.tar.gz，并支持通过环境变量TAR覆盖 tar 命令（对应 RELEASE.md 中记录的 PIO-153：允许在非 GNU 系统如 macOS 上使用 GNU tar）。

提示：脚本在sbt/sbt启动器与project/build.properties（当前为sbt.version=1.2.8，见 project/build.properties）的配合下运行；sbt/sbt是可自举下载 launcher 的封装脚本，见 sbt/sbt。

六、暂存 RC 到 ASF SVN 开发区（步骤 10–13）

ASF 规定所有候选发布物必须先进入SVN 的 dev（开发）区用于投票，而非直接进入 release 区。操作如下：

# 首次使用需检出 dev 区 svn co https://dist.apache.org/repos/dist/dev/predictionio # 在 dev 区创建 RC 专属子目录并放入全部产物 mkdir apache-predictionio-0.15.0-rc1 cp apache-predictionio-0.15.0-* apache-predictionio-0.15.0-rc1 # 若更新了 KEYS，同步拷贝到暂存区 svn commit -m "Apache PredictionIO 0.15.0-rc1"

注意第 11 步中要求暂存区目录内必须包含一份KEYS文件，这是投票者验证签名所必需的公钥来源。

七、Maven 制品发布：Nexus 与 sbt-sonatype（步骤 14–15）

PredictionIO 的核心模块会以 Maven 制品的形式发布到 Apache Nexus，供引擎模板（engine template）以依赖方式引用。为此需要配置 Sonatype 凭据。

7.1 配置 sonatype.sbt

文档要求将以下配置写入~/.sbt/1.0/sonatype.sbt：

publishTo := { val nexus = "https://repository.apache.org/" if (isSnapshot.value) Some("snapshots" at nexus + "content/repositories/snapshots") else Some("releases" at nexus + "service/local/staging/deploy/maven2") } credentials += Credentials("Sonatype Nexus Repository Manager", "repository.apache.org", "<YOUR APACHE LDAP USERNAME>", "<YOUR APACHE LDAP PASSWORD>")

这里体现了 SNAPSHOT 与正式版本两种发布通道的区分：快照直接进snapshots仓库，正式版则进入 Nexus 的staging（暂存）流程，需要人工关闭暂存仓库后才会被正式接受。

7.2 本地验证与签名发布

sbt/sbt +publishLocal sbt/sbt +publishSigned +storage/publishSigned

其中+前缀是 sbt 的跨版本交叉编译语法。publishSigned由 project/plugins.sbt 中引入的sbt-pgp（com.jsuereth % sbt-pgp % 1.1.2）提供，负责对制品做 GPG 签名；+storage/publishSigned则是将根 build.sbt 中聚合的storage项目（包含 elasticsearch、hbase、hdfs、jdbc、localfs、s3 六个存储后端子模块）一并签名发布。Nexus 交互由sbt-sonatype（project/plugins.sbt）驱动，发布完成后需要在 Nexus Web 界面关闭 staged repository，等待正式发布。

八、发起社区投票：[VOTE] 邮件（步骤 16）

RC 暂存完成后，向 PredictionIO dev 邮件列表发送投票邮件。文档给出了完整模板：

Subject: [VOTE] Apache PredictionIO 0.15.0 Release (RC1) This is the vote for 0.15.0 of Apache PredictionIO. The vote will run for at least 72 hours and will close on Apr 7th, 2017. The release candidate artifacts can be downloaded here: https://dist.apache.org/repos/dist/dev/predictionio/apache-predictionio-0.15.0-rc1/ Test results of RC1 can be found here: https://travis-ci.org/apache/predictionio/builds/xxx Maven artifacts are built from the release candidate artifacts above, and are provided as convenience for testing with engine templates. The Maven artifacts are provided at the Maven staging repo here: https://repository.apache.org/content/repositories/orgapachepredictionio-nnnn/ All JIRAs completed for this release are tagged with 'FixVersion = 0.15.0'. You can view them here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320420&version=12337844 The artifacts have been signed with Key : YOUR_KEY_ID Please vote accordingly: [ ] +1, accept RC as the official 0.15.0 release [ ] -1, do not accept RC as the official 0.15.0 release because...

邮件要点包括：投票最短持续 72 小时、RC 产物下载地址、CI 测试结果地址、Maven 暂存仓库地址、该版本已完成的 JIRA 列表、签名密钥 ID，以及 +1/-1 投票方式。这一步是 Apache 社区"社区共识（community consensus）"治理原则的直接体现——任何 RC 必须经过至少 72 小时的公开投票期。

九、正式发布与收尾（步骤 17–27）

9.1 更新 RELEASE.md 与创建正式标签（步骤 17–18）

投票通过后，首先更新仓库根目录的 RELEASE.md——该文件本身即是"发布说明与新闻"的载体，包含从 0.8.6 到 0.14.0 的版本历史、破坏性变更（Breaking changes）、新特性（New Features）、行为变更（Behavior Changes）与贡献者名单（Credits），例如 0.14.0 记录的 Elasticsearch 6.x 支持（PIO-168）、Spark 2.4 支持（PIO-199）等。随后创建正式发布标签（如v0.15.0）。

9.2 生成正式发布产物并发布 Maven（步骤 19）

对正式版本（而非 RC）重复步骤 6–8（打包、签名、SHA512）与步骤 15（publishSigned）。也就是说，正式产物与 RC 产物在流程上完全对称，只是版本号不再带-rcN后缀、走的是正式发布通道。

9.3 发布到 SVN release 区并清理旧版本（步骤 20–24）

# 检出 release 区（实际发行区域） svn co https://dist.apache.org/repos/dist/release/predictionio/ mkdir 0.15.0 # 将二进制发行版从 dev 树拷贝到 release 树 # 将官方发布版拷贝到 release 树 # 若更新了 KEYS，同样拷贝到该区域 svn delete 0.14.0 # 按 ASF 镜像策略移除旧版本 svn commit -m "Apache PredictionIO 0.15.0"

ASF 的分发镜像只保留有限数量的历史版本，因此发布新版时需要通过svn delete移除旧版本目录（示例中删除了0.14.0）。

9.4 文档、JIRA 与公告（步骤 25–27）

1. 升级文档：将破坏性变更记录到项目网站的升级页面（upgrade），供用户平滑迁移；
2. JIRA 标记：在 Apache JIRA 上将0.15.0标记为已发布（Released）；
3. 发送公告：向announce、user、dev三个邮件列表发送 [ANNOUNCE] 邮件。文档给出了完整模板：

Subject: [ANNOUNCE] Apache PredictionIO 0.15.0 Release The Apache PredictionIO team would like to announce the release of Apache PredictionIO 0.15.0. Release notes are here: RELEASE.md Apache PredictionIO is an open source Machine Learning Server built on top of state-of-the-art open source stack, that enables developers to manage and deploy production-ready predictive services for various kinds of machine learning tasks. The release artifacts can be downloaded here: https://www.apache.org/dyn/closer.lua/predictionio/0.15.0/apache-predictionio-0.15.0-bin.tar.gz All JIRAs completed for this release are tagged with 'FixVersion = 0.15.0'; the JIRA release notes can be found here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320420&version=12337844 Thanks! The Apache PredictionIO Team

至此，一个版本从密钥准备到全球分发公告的完整生命周期结束。

十、发布流程与仓库源码的映射关系速查

为便于 PMC 成员实际操作与 Agent 检索，下表将流程步骤与仓库内对应文件一一对应：

结语

Apache PredictionIO 的 PMC 发布流程是一套"工程 + 治理"双轮驱动的标准范式：工程侧通过git archive、gpg签名、SHA512 校验和、make-distribution.sh、sbt-sonatype 保证产物的可复现与可验证；治理侧通过 KEYS 公钥体系、SVN dev/release 双区、72 小时投票、JIRA 标记与多列表公告保证发布决策的公开透明。理解这套流程，不仅能直接支撑 PredictionIO 的版本维护工作，也能为任何 Apache 级别开源项目的发布工程提供一份可复用的操作蓝本。仓库内的 make-distribution.sh、RELEASE.md 与 KEYS 是随时可查阅的第一手参考。

• 机器学习
• 后端
• 大数据