回撸Rust China Conf 2020 之《Rust企业级应用最佳实践》

本篇回撸一把《Rust企业级应用最佳实践》，讲者分享了Rust应用的“最后一公里”中所解决的问题和有效实践，非常接地气。

Speaker: Liao Yiming (廖意明)

视频 PDF

1. 面向CI的Cargo工具

stages:
    - build
build_release:
    stage: build
    script:
        - ...
        - cargo fmt
        - cargo fix
        - cargo fix
        - RUSTFLAGS="-D warnings" cargo clippy
        - cargo build --release

本章节分享的最佳实践：在做人工的Code Review之前，尽可能的利用自动化检查工具进行预审查，并展示了一个构件脚本。

这个脚本要求开发者在提交时，要在本地做好cargo fmt、fix、clippy，否则CI流水线是无法通过的。

脚本中有两处cargo fix，这是一个trick：如果在第一处cargo fix修改了代码，就会导致第二个cargo fix因为code dirty而无法通过。

接下来的cargo clippy的 -D warnings参数，表示构建不接受warning，开发者可以在代码中添加#![deny(warnings)]，或者在本地运行cargo clippy -- -D warnings来检查是否满足该要求。

2. SemVer

image

本章节介绍了定义依赖时的语义化版本的概念，如上图。

下面是一些自定义升级策略的例子。其中"^0.2.3"之所以不能自动升级到“1.0.0”是因为在语义化版本中，第一位Major位为0，表示不稳定，所以升级幅度会有限制。

[dependencies]
kov = "=1.2.3"          # 可用版本：1.2.
kov = "^1.2.3"          # 可用版本：>= 1.2.3 且 < 2.0.0
kov = "^1.2"            # 可用版本：>= 1.2.0 且 < 2.0.0
kov = "^1"              # 可用版本：>= 1.0.0 且 < 2.0.0
kov = "^0.2.3"          # 可用版本：>= 0.2.3 且 < 0.3.0
kov = "^0.2"            # 可用版本：>= 0.2.0 且 < 0.3.0
kov = "^0.0.3"          # 可用版本：>= 0.0.3 且 < 0.0.4
kov = "^0.0"            # 可用版本：>= 0.0.0 且 < 0.1.0
kov = "^0"              # 可用版本：>= 0.0.0 且 < 1.0.0
kov = "*"               # 可用版本：>= 0.0.0
kov = "1.*"             # 可用版本：>= 1.0.0 且 < 2.0.0
kov = "1.2.*"           # 可用版本：>= 1.0.0 且 < 2.0.0
kov = ">1.2.3"          # 可用版本：> 1.2.3
kov = ">1.2.3 <1.2.17"  # 可用版本：> 1.2.3 且 < 1.2.17
kov = "<=1.2.3"         # 可用版本：<= 1.2.3

如果大家想去试更多的case，可以试下这个在线计算器semver calculator。

讲者在本章节分享了自己遇到的几次“饭后编译失败”的经历。造成的原因是：语义化版本的兼容性，是由开发者人为保证的，所以有可能出错。如果出现了因为Cargo Update导致的编译失败，可以通过前面的kov = "=1.2.3"强制锁定版本来解决。

本章关于语义化版本的最佳实践：

• 不要使用通配符*；
• 尽可能明确版本“x.y.z”，并通过cargo update -p cratename来指定升级，而不要cargo update进行大面积升级；
• 对于crate提供者，一旦出现兼容性问题，马上进行cargo yank，可以阻止还没用过问题版本的用户看到此版本。

3. 私库依赖

Cargo.toml中的依赖，除了指定语义化版本之外，在私有代码场景中，可以用git依赖的方式，比如下面列举的默认分支、指定分支、commit id、tag等等。

rand = {git="https://github.com/rust-lang-nursey/rand"}
rand = {git="https://github.com/rust-lang-nursey/rand", branch="next"}
rand = {git="https://github.com/rust-lang-nursey/rand", rev="39a7x2"}
rand = {git="https://github.com/rust-lang-nursey/rand",tag="0.3.1"}

但是，这会带来“多模块依赖问题”的问题。如下图所示：

image

来源：讲者PPT

Error: perhaps two different version of crate 'x' are being used?

讲者分享了他发现的一个解决方案：在Rust 1.34.0引入的Alternate Register，可以向私有库进行语义化版本的发布：

• ~/.cargo/config

[registries]
my-registry={index="https://my-intranet:8080/git/index"}

• cargo login --registry=my-registry
• cargo publish --registry=my-registry
• Cargo.toml

[dependencies]
other-crate={version="1.0",registry="my-registry"}

本章的建议：避免由开发者在本地进行随意的发布，应该在CI流水线在合适的时机进行自动化发布。

4. 构建脚本

本章分享了Rust的构建脚本，在Cargo.toml中的package中添加build项，如下图所示。其中build.rs文件目录同Cargo.toml即可。

[package]
name = "demo"
version = "1.0.0"
edition = "2018"
build = "build.rs"

构建脚本，可以把很多额外的信息动态加入到编译后的可执行文件中，包括可执行文件的当前版本、编译环境、系统版本等，方便追溯。

为了更快捷的创建构建脚本，讲者开源了一个构建脚本工具shadow-rs：shadow-rs allows you to recall properties of the build process and environment at runtime, including:

• Cargo.toml project version
• Dependency information
• The Git commit that produced the build artifact (binary)
• What version of the rust toolchain was used in compilation
• The build variant, e.g. debug or release
• (And more)

来加颗star吧。