一个基本的 Coverity 部署由以下两部分组成：

Coverity Analysis – 分析代码库。

Coverity Connect – 管理代码缺陷；它使用数据库来存储分析结果。

部署架构解决这两个组件的配置问题。不同类型的部署支持不同的工作流。

分析可以是本地分析、中央分析或两者的组合。部署架构的模型很多，从在一台机器上运行分析到具有自动分类和分配的全自动连续集成 (CI) 不一而足。以下各节提供了两个基本示例。

中央分析
在中心分析中，代码是在共享的构建服务器上构建和分析的。下图展示了一个基本的 Coverity 部署。如图所示。Coverity Connect 和它的嵌入式数据库一起安装在一台单独的主机上。该过程将包括以下步骤。

Coverity Analysis 安装在一台构建服务器上，在该服务器上将对构建的构件进行分析。

在每次构建和分析运行结束时，发现的代码问题会作为问题提交给 Coverity Connect。

开发人员使用客户端连接到 Connect 服务器，并检出自己负责的代码。

开发人员检查发现的问题，并尝试解决这些问题。

开发人员再次检查他们的代码，并在预定的时间运行另一个分析。

当多个开发人员执行第 3-5 步时，Coverity Connect 会跟踪每个问题的历史记录和演变情况，以便经理查看趋势并生成进度报告。

图 1. 中央分析

本地和中央分析
在刚才描述的部署示例中，所有的代码分析都是在构建服务器上集中执行的。下面的部署示例通过将 Coverity Analysis 添加到开发人员的机器上来增强前一个示例。此部署支持如下工作流。

Coverity Analysis 安装在一台构建服务器上，在该服务器上将对构建的构件进行分析。

在每次构建和分析运行结束时（每天或每当检入代码时都会发生），发现的代码问题会作为问题提交给 Coverity Connect。

开发人员使用他们的客户端浏览 Connect 服务器，并审查已分配给他们的问题。

开发人员在本地进行分析，并解决问题。

开发人员检入修复的代码。

中央构建也会运行分析，以发现代码与其他签入代码的交互所产生的问题。

开发人员解决在中央分析中发现的任何其他问题，并再次检入代码。

为了支持这种模型，在开发人员的 IDE 中安装了 Code Sight 或 Coverity Desktop 插件，以便开发人员直接在 IDE 中查找、检查、修复和分析代码。

图 2. 混合分析

多个测试模型的优势
不同测试模型的可用性，可以在不疏远喜欢控制流程的开发人员的情况下引入静态分析。您可以先在每晚和每周的 Jenkins 连续集成构建中部署 Coverity，而不是强迫他们使用其他工具。然后，开发经理可以将 Coverity 的结果作为工作项目、电子邮件或代码审查中的问题来呈现。随着开发人员选择解决他们自己的问题，避免破坏构建并将其姓名从“黑名单”中删除，自愿手动使用 Coverity 的人数将会增加。

部署选项
Coverity 支持许多部署选项。基本选项涉及以下内容：

使用嵌入式 PostgreSQL 数据库或配置 Coverity Connect 以使用您自己的外部 PostgreSQL 数据库。

将 Coverity Connect 部署为独立应用程序或部署在群集中。

配置多个 Coverity Analysis 实例以将问题提交到 Coverity Connect 服务器。