回撸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 fmtfixclippy,否则CI流水线是无法通过的。

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

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

2. SemVer

回撸Rust China Conf 2020 之《Rust企业级应用最佳实践》_第1张图片
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"}

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

回撸Rust China Conf 2020 之《Rust企业级应用最佳实践》_第2张图片
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吧。

你可能感兴趣的:(回撸Rust China Conf 2020 之《Rust企业级应用最佳实践》)