工作流
如果您了解基本命令,已经过入门,基本用法,并且对发布有初步了解,那么下一步可能是为您的项目和团队确定一个工作流。
本节正在进行中,其中包含各种推荐步骤和可能的默认配置,以便在使用 Erlang 工具链时获得良好的体验。
选择合适的项目类型
项目类型 | 推荐模板 | 备注 |
---|---|---|
简短的脚本或工具 | escript | 您分发的用户需要安装 Erlang。 C 语言中的依赖项既不是简单包含也不是重新分发 |
一个完整的、自包含的可执行系统 | release 或 umbrella | 这是 Erlang 系统推荐的生产部署方式。 有关发布的更多详细信息,请参阅发布部分 |
一个将在其他系统中使用的库 | lib 或 app | 对于包含模块的无状态库,使用lib ;对于具有监管树的有状态库,使用app |
多个库的集合 | umbrella | 这是支持的项目形式之一,其中使用了多个顶级应用。 这些项目通常不能用作依赖项。 对于可用作依赖项的项目,请参阅如何声明 git_subdir 依赖项 |
设置依赖项
项目的 基本配置至少应执行两件事
-
始终跟踪
rebar.lock
文件 -
忽略
_build
目录
跟踪锁定文件将使您能够进行可重复的构建,并允许 Rebar3 执行诸如在切换分支时自动重新更新依赖项之类的操作。
🚧
_build
目录可以安全删除,但您不需要这样做Rebar3 跟踪在您的 `rebar.config` 文件中声明的所有应用程序,并且应该能够跟踪所有必需的更改。在某些极端情况下,这可能无法实现,并可能导致奇怪的错误,特别是在您更改项目结构时。如果您要从单个应用程序项目迁移到伞形项目(即所有源文件从 `src/` 移动到 `apps/myapp/src`)或相反,则 `_build` 目录中的各种工件很可能会相互冲突。在这种情况下,请将其删除并请求全新构建。
接下来,您需要做的就是向您的项目添加依赖项。有关此信息,请参阅依赖项部分。但是,添加依赖项不会自动将其集成到您的项目中。
{deps, [...]}
配置值告诉 Rebar3 要获取、下载和跟踪哪些依赖项,但仅此而已。然后,您必须配置您的应用程序以使用该依赖项
- 如果您的应用程序在运行时需要依赖项才能正常工作(例如,您需要 Web 服务器或直接调用库),请将其添加到应用程序的
.app.src
文件中,位于{applications, [stdlib, kernel, ...]}
元组下。这将使 Erlang VM 知道在依赖项不存在的情况下不要启动您的应用程序 - 如果仅在发布时需要依赖项(例如,
observer
或recon
,它们是您的应用程序可能不依赖的调试工具,但您希望将其捆绑在一起),则需要将该应用程序显式添加到{releases, ...}
配置元组中。该元组上的任何依赖项也将包含其传递依赖项。
其他构建工具往往不区分这些类型的项目包含,但 Rebar3 试图严格规定应包含或不包含的内容。它可以让您进行特定的构建,例如 escript 或测试发布,这些构建不需要 Wx 图形工具包之类的特定工具链即可运行。
升级依赖项
升级依赖项需要两个步骤
-
更新索引缓存
-
更新依赖项本身
第一步是必需的,因为 Rebar3 会缓存您之前获取的 Hex.pm 存储库包和版本。这使构建工具能够更快地运行,而无需在计算机上存在所有已知和所需版本时对网络进行无用的调用。但是,当存在新版本时,Rebar3 不会自动知道。要告诉它去获取已知包的新版本定义,请调用
$ rebar3 update
这将使 Hex 包保持最新,但不会修改现有项目。
更改现有项目定义的唯一方法是修改锁定文件。这可以通过调用以下命令轻松完成:
$ rebar3 upgrade <depname>
这将更新锁定文件定义,并在下次构建时,将获取并编译新副本。如果传递依赖项也已升级,则将检测和处理。
您应尽可能避免删除锁定文件,如果您需要升级多个依赖项,则可以调用 rebar3 upgrade dep1,dep2,dep3
。如果您想更新所有依赖项,请调用 rebar3 upgrade --all
,这在小型项目中是可以的,但在大型项目中,您可能希望逐步进行。
为常用任务创建别名
更复杂的项目可能会运行多个工具。例如,您可能希望运行 xref
以查找死代码,dialyzer
以进行类型分析,ct
以进行通用测试套件,cover
以进行覆盖率分析,等等。
与其手动调用所有任务,不如使用别名创建一个简单的命令来运行多个任务
{alias, [
{check, [xref, dialyzer, edoc,
{proper, "--regressions"},
{proper, "-c"}, {ct, "-c"}, {cover, "-v --min_coverage=80"}]}
]}.
此配置将允许调用 rebar3 check
,它将按顺序运行以下操作
xref
分析死代码和对不存在的函数的调用dialyzer
检查不一致和类型错误- 构建项目文档,以确保它能够在没有错误的情况下构建
- 在
proper
中运行回归测试(使用PropEr 插件) - 在编译时使用覆盖率分析运行 PropEr 中的常规属性
- 在编译时使用覆盖率分析运行通用测试测试套件
- 运行
cover
分析,并将结果输出到 shell。此别名还确保如果代码覆盖率低于 80%,则命令将失败
只要某个任务失败,整个命令就会中断。您可以根据需要调整别名。
📘
优化任务延迟
节省时间的技巧是先运行时间较短的任务。例如,
xref
会发现dialyzer
也发现的一些问题,但速度快得多。在您的别名中先运行xref
再运行 Dialyzer 将为您提供更快的反馈循环。
各种工具的推荐配置
某些 Rebar3 配置和默认值可能过于宽松或过于严格。但是,由于对向后兼容性的承诺,我们无法始终更改和调整它们,因为这可能会破坏依赖于这些特定配置的项目。
以下是启动新项目时可能用作新默认值的一些配置的集合。
{dialyzer, [
{warnings, [
%% Warn about undefined types and unknown functions
unknown
]}
]}.
{xref_checks,[
%% enable most checks, but avoid 'unused calls' which is often
%% very verbose
undefined_function_calls, undefined_functions, locals_not_used,
deprecated_function_calls, deprecated_functions
]}.
{profiles, [
{test, [
%% Avoid warnings when test suites use `-compile(export_all)`
{erl_opts, [nowarn_export_all]}
]}
]}.