IBM Cognos 最佳实践: IBM Cognos BI:在环境之间部署内容

文档性质:指南;产品:IBM Cognos BI;关注领域:管理

本文旨在为开发商业智能内容和将其从一个环境部署到另一个环境提供指导。例如,将内容从开发环境部署到质量保证 (QA) 环境,然后再部署到生产环境中。

免费下载:IBM® Cognos® Express V9.5 或者 Cognos® 8 Business Intelligence Developer Edition V8.4 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

目的

本文旨在为开发商业智能内容和将其从一个环境部署到另一个环境提供指导。例如,将内容从开发环境部署到质量保证 (QA) 环境,然后再部署到生产环境中。

适用范围

本文针对 IBM Cognos 8.4.1 和 IBM Cognos 10.1 而编写并已经过测试。

例外与除外责任

本文不会讨论 IBM Cognos BI 软硬件配置或性能调优,也不会提供有关配置部署的分步指导。这类信息可在核心文档中找到。

假设

本文假设作者拥有 IBM Cognos BI 方面的经验,特别是 IBM Cognos BI 报表管理和 IBM Cognos Framework Manager 方面的经验。


概述

尽管人们熟悉开发、质量保证 (QA) 和生产环境的概念,但仍然经常出现 IBM Cognos BI 最佳实践方面的问题。这些问题的一些示例包括:

  • “我们需要多少物理环境?”
  • “哪里是实现安全性的最佳地点?”
  • “我们应当在哪里创建报表视图、作业和进度表?”
  • “我们需要报表数据库的多少实例才能适应开发、QA 和生产?”

针对不同对象,答案可能有所不同;在某些情况下变化较小,而在其他情况下变化较大。虽然大多数人会同意对 BI 生命周期使用三层方法,即开发、QA 和生产这三层,但他们通常无法就需要多少环境和数据库或所需的硬件达成一致。

本文会探讨 BI 生命周期三层方法(如下表所述,如图 1 所示)的不同实现的优缺点。还会就何时何地实现您的 BI 项目的哪些方面(比如安全性、创建进度表、作业,等等)提供一些指导。

开发QA生产
创建/编辑,测试和发布 Framework Manager 包通过有限的用户群验证报表功能、数据和安全性验证内容并开始使用
按需组织门户文件夹结构测试报表、作业和进度表的性能实现任何获准的生产变更
创建 & 测试报表/报表视图,应用安全性部署内容
部署内容
图 1:三层部署流程图显示了开发、QA 和生产环境任务
图 1:三层部署流程图显示开发、QA 和生产环境任务

图 1 显示了如何开发、测试和组织模型和报表。一旦内容就绪,就可以将它迁移到 QA 环境中进行验证和测试,然后将其迁移到生产环境中供使用者进行使用。

物理环境和 IBM Cognos BI 实例

重要的是要注意,本文中讨论的三个环境(开发、QA 和生产)不一定是指 IBM Cognos BI 的三个独立实例或者三个物理环境。例如,开发和 QA 可是是一组硬件上的两个 IBM Cognos BI 实例。开发和 QA 也可以位于由文件夹结构隔开的一个 IBM Cognos BI 实例中,一个文件夹包含开发内容,另一个文件夹包含 QA 内容。理想情况下,每个环境都会位于三个独立的 IBM Cognos BI 实例中,每个都在其自己的硬件上。这就降低了开发、测试和生产活动之间的风险和资源冲突。为了确保性能测试的准确性,QA 环境将是生产环境的一个镜像。如果不是,请确保配置 QA 环境能够使正使用的物理硬件取得最大的获益。如果您将多个实例放到一组硬件上(这包括虚拟化的使用),可能会为您的环境引入单点故障。在任何实现中都应将故障转移考虑在内。

选择部署方法时的因素

您选择的部署方法将取决于多个因素,比如成本、资源、策略、首选项,等等。有些人可能喜欢具有较少服务器和较少工作流程的更精简的方法,而使用基于风险管理的严格策略的其他方法在迁移到生产环境之前可能需要更多的检查和平衡。

IBM Cognos BI 的第三方内容管理选项

还应当指出的是,第三方软件旨在帮助精简和简化部署流程。来自 Motio 的 MotioCI、来自 BSP software 的 MetaManager 和来自 Envisn 的 NetVisn 都是基于 IBM Cognos BI SDK 的三个软件示例,它们丰富了维护和部署流程。该软件允许对 IBM Cognos BI 内容存储库中的所有对象进行细粒度的访问,并且能够让您轻松从一个环境备份和部署内容到下一个环境。如果本文给出的指导与您的策略或需求相冲突,可以考虑使用第三方工具来增强部署和元数据管理体验。

本文将仅为 “开箱即用” 功能以及它如何与全文将讨论的每个层级相关联提供指导。为简单起见,文本还将侧重于 IBM Cognos BI 的三个物理实例,一个用于开发,一个用于 QA,一个用于生产。


沙箱

一个尚未讨论、但绝对值得在此一提的环境是测试环境或沙箱。这将是 IBM Cognos BI 的一个独立实现,因为可以将它用于 “概念验证” 之类的工作。

例如,测试配置文件更改、实现门户定制、测试软件升级或测试内容迁移,都有可能破坏环境。使用沙箱可以保护开发、QA 和生产环境免受此风险。

将该环境作为一个映像会很理想,这样当一些测试使环境无法使用时,您就可以轻松恢复到某个时间点。


开发环境

本节将探讨开发环境中通常应当发生的活动,如图 2 所示,包含以下任务:

  • 创建/编辑,测试和发布 Framework Manager 包
  • 按需组织门户文件夹结构
  • 创建 & 测试报表/报表视图,应用安全性
  • 部署内容
图 2:强调开发环境任务的三层部署流程图
图 2:强调开发环境任务的三层部署流程图

您需要多少数据源?

在探究各个开发环境任务之前,我们看一下数据源以及您应当为不同 IBM Cognos BI 实例包含多少实例。

开发环境应当对其自身版本的报表数据源进行检查,因为一些报表开发会在不经意间创建可能影响数据源性能的资源密集型查询。QA 环境可以共享相同的开发数据源,只要性能测试完成时开发被停止,这样就可以获得更准确的性能结果。

要创建一个可预见的测试环境,可以使用具有较少数据集的一个静态版本的数据源,这样开发人员和 QA 测试人员都会知道预期的值是什么,且不必担心不断变化的数据。另一方面,开发人员和 QA 测试人员可能需要对与生产环境中相同的数据进行检查,以诊断使用者报告的某些报表问题或数据问题,并测试报表性能。为此,开发和 QA 环境都可以创建两个数据源的连接,一个连接静态数据库,一个连接生产数据库的镜像。生产环境仅指向生产数据库。这类设置如图 3 所示。

图 3:开发和 QA 环境都指向静态和生产镜像数据库,而生产环境仅指向生产数据库
图 3:开发和 QA 环境都指向静态和生产镜像数据库,而生产环境仅指向生产数据库

使用这类设置,任何有权限同时使用两个数据源连接的用户都会在运行时收到提示,问他们希望使用哪一个连接。只能访问一个连接的用户不会收到提示,且只能使用它们可以访问的那一个连接。

应当对完整的生产数据集在 QA 环境中执行性能和负载测试,以确保在部署到生产环境之前具有准确的结果。同样,QA 环境与生产环境中的硬件规格越接近,测试结果就会越准确。

下面我们看一下图 2 中的流程图中呈现的每个任务。


创建/编辑,测试 & 发布 Framework Manager 包

在开发的这个初始和迭代阶段,主要是设计和测试模型、按需在模型中应用对象和数据安全性、创建数据包并发布到 IBM Cognos BI。该流程是迭代的,因为测试结果或新需求可能需要模型有一些变动。

关于将数据包发布到 IBM Cognos Connection,在发布之前应当考虑数据包的组织。应当将数据包发布到一个有组织的结构中,以便在生产环境中将它最终展示给用户。换言之,确保有存放数据包的最终演示文件夹结构到位。这样做是为了确保可以利用 Framework Manager 的 Analyze Publish Impact 功能。

Analyze Publish Impact 功能用于确定建模变更如何影响现有报表。在使用该功能时,它寻找之前发布的数据包,将其与 Framework Manager 中您的模型进行对比。如果将数据包移入 IBM Cognos Connection,那么 Analyze Publish Impact 功能将不起作用,因为它无法找到发布的数据包来进行比较。由于您可以快速配置 IBM Cognos Framework Manager 指向不同的 IBM Cognos BI 网关(在本例中是您的 QA 或生产环境),您会希望整个环境中的文件夹结构相同,以利用 Analyze Publish Impact 功能。例如,可能有些情况下您想要分析在生产环境中(而非开发或 QA 环境)发布数据包对即席报表的影响。


按需组织门户文件夹结构

您组织门户文件夹结构的方式将取决于多个因素,包括工作流、分类、演示,等等。答案无对错之分,但是这里会提供一些指导和考虑事项。

报表开发工作流

我们首先介绍报表开发工作流和报表组织考虑事项。通常会确定一组报表创建者来为报表使用者创建 “预制” 的报表,通常其工作流包括:

  • 开发和测试报表,维护版本
  • 将完成的报表移动到其最终位置
  • 基于反馈更新报表,然后在最终位置替换它们

创建者在哪里开发其报表是应当考虑的事情。创建者可以在其 My Folders 中开发其报表,并通过报表副本和命名约定(Report 1 version 1,Report 1 version 2,以此类推)维护其开发的版本,然后一旦完成命名,便可将报表的最终版本放在相关的数据包或文件夹中,最终展示给用户。在 My Folders 中进行开发的缺点在于,除系统管理员之外其他人无法访问内容。

另一个选择是在 Public Folders 下新建一个 Report Development 文件夹,创建者可以访问该文件夹并适当进行组织。例如,可以创建文件夹来表示将报表链接到的数据包名称,在此文件夹下可以创建具有创建者名称的文件夹,如图 4 所示。

图 4:开发文件夹包含一个数据包开发文件夹,而后者又包含报表创建者的文件夹
图 4:开发文件夹包含一个数据包开发文件夹,而后者又包含报表创建者的文件夹

这提供了一个更具协作性的环境。可以按需应用安全性来预防人们不小心修改报表。

完成报表的开发之后,可以将报表移到最终演示位置,使用者最终会在这里访问报表。然后将该内容部署到 QA 环境进行测试。由于测试是在 QA 环境中进行的,报表可能需要一些额外工作,此时创建者可以继续在其报表开发位置(My Folders 或 Public Folders 中的一个报表开发位置)处理报表,最后在再次部署到 QA 环境之前在其最终演示位置替换报表。

最终报表应去往何处?

关于 Public Folders 结构的分类,一个经常出现的问题是,“我们应当将报表放在哪里?应当将其放在将报表链接到的数据包还是单独的文件夹中?” 有了开箱即用的功能,这将取决于您打算如何继续部署您的内容。

通过在报表链接到的数据包中保持报表的条理性,很容易就可以跟踪报表并立即知道它们属于哪个数据包,而无需查看其各自的属性。在这种情况下部署数据包及其相关报表很简单。报表创建者仅仅将其最终报表放在其相关的数据包中,然后该包被部署到 QA 环境,如图 5 所示。

图 5:将报表从开发位置移动到数据包中,然后将数据包部署到 QA 环境
图 5:将报表从开发位置移动到数据包中,然后将数据包部署到 QA 环境

测试完数据包及其报表之后,就可以将其部署到生产环境中。

在处理大量报表时,该类报表组织方面的缺点就显现出来了。例如,如果您有数以百计的报表,想对不影响报表的基础数据包模型做修改,则需要将更新的数据包从一个环境部署到另一个需要部署所包含的所有报表的环境中。虽然这可能不会对部署性能有明显的影响,但您仍然没有必要将报表从一个环境移动到另一个环境。这可能还会引入将未被发现的变更部署到报表的风险。某份报告可能已发生更改,但没有人收到通知。这份报表可能被部署到了 QA 环境,未经过测试,随后再部署到生产环境中,此时可能会导致意外的结果。避免这种情况的一种方式就是验证数据包中每个报表的最后修改日期,并确保日期不晚于最后的部署日期。如果晚于最后部署日期,则必须在目标环境中测试该报表。

另一种选择是创建一个与数据包分离开来的文件夹,命名约定是要指示报表被链接到哪个数据包。例如,一个名为 GO Sales 的数据包中的报表可以位于一个名为 GO Sales Reports 的文件夹中。在这种情况下,如有需要的话,可以将报表和数据包分开部署,如图 6 所示。

图 6:将报表从开发位置移到报表文件夹,该文件夹位于一个允许分开部署报表和数据包的特殊数据包中
图 6:将报表从开发位置移到报表文件夹,该文件夹位于一个允许分开部署报表和数据包的特殊数据包中

再次强调,IBM Cognos BI 的核心功能只允许部署数据包和文件夹,而非单个报表。在这里可能会出现相同的问题,即可能不小心将修改后的报表部署到下一个环境中。同样,避免该问题的一种方式是验证文件夹中每个报表的最后修改日期,并确保日期不晚于最后的部署日期。

在某些组织中,这是可以接受的,但有些组织可能要求重新测试部署的对象。在这些情况下,可以创建一个开发文件夹,将所有修改的报表放在其最终位置以及 Deployment 文件夹。然后将 Deployment 文件夹部署到目标位置,将报表从 Deployment 文件夹移到其适当位置,如图 7 所示。

图 7:将报表从开发位置移到报表文件夹,该文件夹位于一个特殊数据包中仅允许分开部署修改的报表和数据包的 Deployment 文件夹中。一旦报表到达目标环境,就将其从 Deployment 文件夹移到其适当位置。
图 7:将报表从开发位置移到报表文件夹,该文件夹位于一个特殊数据包中仅允许分开部署修改的报表和数据包的 Deployment 文件夹中。一旦报表到达目标环境,就将其从 Deployment 文件夹移到其适当位置。

一旦将报表全部移到其目标位置,就应该开始清理 Deployment 文件夹,让 Deployment 文件夹为下一轮部署做好准备。

Deployment 文件夹方法可以双向工作。例如,如果有人在生产环境中创建了一个可由报表开发人员增强且可供用户使用的报表,可以使用 Deployment 文件夹方法将其部署回开发环境。

Deployment 文件夹方法需要报表开发人员、进行部署的管理员和潜在的报表管理员之间有明确的沟通(如果不是同一人在进行部署),以确保将报表部署到目标环境中的正确位置。

在将对象从一个环境移动到另一个环境时,如欲获得更细粒度的控制,可以考虑使用之前提到的一些第三方软件。这样可以减少流程间的相互制衡,让部署流程更简单,从而允许您使用一个简单的分类,如该主题的第一幅图(图 5)所示。

有时候可能需要包含位于不同数据包的若干报表的文件夹。例如,一个供高层管理人员使用的文件夹可能包含有关业务各个方面的若干报表,每一个都位于不同的数据包中。在这种情况下,需要查明报表被链接到哪个数据包,还需要查看报表属性。不要将报表移到这种类型的文件夹中,可以考虑使用快捷键或报表视图。不过在使用快捷键时,您需要考虑到,在重命名或移动源报表时,快捷键可能会失效。而报表试图则更功能强大且能提供更高的灵活性,这将在下一节加以讨论。

创建 & 测试报表/报表试图,应用安全性

一旦确定了报表开发工作流(之前讨论过),创建者只需创建和测试其报表,直至他们觉得满足了报表需求为止。完成这些之后,他们将其报表放在最终演示位置,以及可能会有的 Deployment 文件夹。创建者可能还希望在必要时创建和测试报表视图。

应当何时何地创建报表视图?

在尝试扩展报表、根据筛选来满足不同标准时报表视图是一个不错的选择。例如,一个报表可以容纳多个区域,做法是为每个区域创建一个报表视图,为每个报表视图提供适当的区域筛选器。创建者会测试这些报表视图来确保筛选器按预期的方式运行。

如前所述,当在门户中收集不同位置提供的一组自定义报表为特定群体提供服务时,报表视图很有用。例如,可以使用一组报表视图来呈现执行报表,如图 8 所示。

图 8:来自 Package 1 和 Package 2 的报表呈现为 Executive Reports 文件夹中的报表视图
图 8:来自 Package 1 和 Package 2 的报表呈现为 Executive Reports 文件夹中的报表视图

通过这种方式,报表使用者可以到门户中的特定位置查看感兴趣的报表,同时原始报表仍然根据您确定的分类法进行组织。

如果重命名或移动原始报表,报表视图不会受影响。但是,如果您重命名或移动底层报表,则需要部署该内容,让报表视图在目标环境中工作。

重命名或移动内容然后进行部署

如果您重命名或移动对象,那么应该了解到,在部署修改后的内容时,只会将该修改后的内容添加到目标环境中。例如,在开发和 QA 环境中的 GO Sales 数据包中都有一个名为 GO Sales Revenue 的报表。如果在开发环境中将报表重命名为 GO Sales Revenue by Region,然后将其部署到 QA 环境中,它不会将现有 GO Sales Revenue 报表替换为新命名的报表。它仅会将 GO Sales Revenue by Region 报表添加到目标位置。这与您在 OS 文件系统上看到的是同一类型的行为。如果您的目的是重命名或移动项目并将其反应在目标环境中,那么您可以在部署之前删除目标环境中的文件夹和数据包,或者将新内容导入目标环境并手动清除不再需要的项目。

应当何时何地应用安全性?

本文不会详细介绍如何应用安全性,但会提供一些有关考虑事项的指导。

您可以使用 Cognos 命名空间中定义的组和角色或来自身份验证提供程序命名空间的用户和组来保护 IBM Cognos BI 内容。使用来自 Cognos 命名空间的组和角色,安全性可以从一个环境移植到另一个,而不管使用的身份验证提供程序是什么。但是,当您从一个环境到另一个环境进行部署时,如果身份验证提供程序不同,您就需要双倍的努力。在这些情况下,您将需要添加来自身份验证命名空间的用户和组到 Cognos 命名空间中的组和角色,因为从一个环境到另一个环境它们是不同的。

如果您为每个环境使用相同的身份验证源实例,可以在开发或 QA 环境中实现安全性,不过在开发环境中实现安全性有助于防止无意间覆盖 QA 环境中应用的安全性。最好有一个事实源从开发环境转到 QA 和生产环境,以降低因一个环境中所做的工作而丢掉另一个环境中所做工作的风险。不管是那种情况,您可能都要在部署到生产环境之前实现安全性,以降低暴露机密数据的风险。

如果您的环境使用来自同一供应商的身份验证提供程序的不同实例,例如,一个实例用于开发和 QA,一个用于生产,您必须确保它们是相互间的镜像,且 IBM Cognos Configuration 的配置对于每个环境中的命名空间是一样的。这将确保在从一个环境到另一个环境进行部署时没有安全冲突。

为质量保证环境创建部署

在开发环境中审查报表、报表视图和安全性之后,便可将内容部署到 QA 环境。

部署中包含的内容将取决于您处于开发和测试流程的哪个阶段。例如,首次从开发到 QA 或从 QA 到生产环境部署内容时,您可能希望包含数据源、登记表和访问权限,甚至希望包含部署整个 Content Store,这样您就无需在目标环境中进行重复工作(注意:如果在不同时间会有多个项目被部署,部署整个内容存储库通常仅针对要部署的第一组内容)。在随后的部署中,您可以选择包含更少的内容,或更改部署配置来预防重写目标环境中所做的工作。

如果您要定期进行部署,可以自动化部署过程。部署存档的默认输出位置是 <IBM Cognos BI install location>/Deployment。您可以在 IBM Cognos Configuration 中将该位置改为可由源和目标 IBM Cognos BI 环境访问的常见网络驱动器。设置可在 Environment > Deployment 文件位置上找到。IBM Cognos BI 服务必须作为一个可访问网络位置的用户运行。一经配置,就可以由源环境基于一个进度表定期生成部署导出,然后按照预定的部署导入,并由目标环境接收。


质量保证环境

本节将深入研究通常会在 Quality Assurance (QA) 环境中发生的活动,如图 9 所示,包含以下任务:

  • 通过有限的用户群验证报表功能、数据和安全性
  • 测试报表、作业和进度表的性能
  • 部署内容
图 9:强调 QA 环境任务的三层部署流程图
图 9:强调 QA 环境任务的三层部署流程图

从开发环境导入部署

现在您有了来自开发环境的部署包,接下来可以将其导入 QA 环境了。

如果是首次将开发环境中的内容导入 QA 环境,可能要部署整个内容存储库。对于随后的内容部署,根据任务,您可以只需部署某些数据包、文件夹、报表等。

通过有限的用户群验证报表功能、数据和安全性

在将内容导入 QA 环境之后,应该该让有限的用户群(不是 IBM Cognos BI 中的管理员)来测试报表了。为了得到最准确的结果,这些用户应当熟悉数据。

正如 “开发环境” 一节所述,QA 环境可以有两个对数据包的数据源连接;一个连接到较小的、一致的数据集,另一个连接到生产数据库的一个镜像。这允许测试用户对有限的数据集执行一致性测试,或对全部数据集进行测试来验证报表使用者将看到的最新数字,并测试性能。

有限的用户群还会测试安全性。他们会查看自己是否拥有对 Studios 的适当访问、是否有正确的功能,并检查报表了解模型对象和行级数据安全性是否按预期工作。

测试报表、作业和进度表的性能

报表性能是要执行的最重要的测试之一。对于一个模拟生产环境的环境,可以根据总执行时间度量报表。另外,报表管理员可以看到报表在满负荷下将如何运行,并看看它们是否落在可接受的业务参数范围内。

如果性能是可接受的,那么应当通知开发人员,且应遵循标准的故障排除实践,比如检查报表 SQL 和报表设计的效率。

知道执行报告的方式会有助于调度。根据业务需求,报表调度可以发生在任何时间,但是有几点要考虑。您应当考虑在非高峰时间调度资源密集型报表,以减少服务器上的负载。适当地调度报表。例如,应当按月运行月度报表,不能超过这个频率,或者可能仅基于某个事件或触发器(比如数据库刷新)运行一些条目。

创建作业将有助于减少调度管理。一个作业是报表、视图和/或单一进度表内其他作业的一个集合。

在部署到生产环境之前的最后检查

完成所有测试和验证之后,创建生产环境的部署之前是对总体报表结构、报表/报表视图名称等进行最后检查的一个好时机,因为该部署表示使用者将在生产环境中看到什么。

如果需要对报表、安全性、结构等做更改,应当将其发送回开发环境,然后向前滚动,以维护环境之间的一致性。

为生产环境创建部署

在 QA 环境中测试完所有报表功能、安全性、报表性能、作业和进度表之后,就可以将内容部署到生产环境了。

首次部署时,可以创建整个内容存储库的部署,其中包含最终用户查看/运行其报表所需的一切。随后的部署可以根据用户需求减少内容,比如某个文件夹、数据包等。同样,如果您有多个项目要在不同时间部署,通常仅对准备初步部署到下一个环境的第一组内容或项目部署整个存储库。

如 “开发环境” 一节所述,如何部署内容以及部署什么内容将取决于偏好、工具和需求。正如在开发环境中,您也可以将部署自动化,将部署存档放在您的生产环境可以访问的网络位置上。对于数据包和文件夹内找到的报表和其他对象的部署,您可以选择使用本文前面描述的部署文件夹方法,或者使用第三方工具。


生产环境

本节将探究通常应当在生产环境中发生的活动,如图 10 所示,包含以下任务:

  • 验证内容并开始使用
  • 实现任何获准的生产变更
图 10:强调生产环境任务的三层部署流程图
图 10:强调生产环境任务的三层部署流程图

生产环境应当用于查看报表输出或创建和运行即席报表。对现有 “预制” 报表的任何开发都应在开发环境中完成,并通过现有基础架构遵循本文建议的步骤进行迁移。

从 QA 环境导入部署

到生产环境的初始部署可以是来自 QA 环境的一个完整内容存储库部署。这将最大限度地减少所需的工作,为随后的部署建立基础。QA 和生产环境应当匹配,以确保顺利地完成部署。这包括身份验证提供程序和数据源。

在随后的部署中,一旦 QA 环境中的内容准备移动到生产环境中,就可以使用一些 “开箱即用” 选项来部署内容,如本文前面所述。让我们来快速回顾一下,这些选项将用来部署:

  • 还包括其相关报表的数据包
  • 数据包和包含数据包特定报表的相应文件夹
  • 一个部署文件夹,仅包含将要部署、然后移到目标环境中适当位置的对象

再次提醒,MetaManager 或 NetVisn 等第三方工具的使用有助于从一个环境到另一个环境部署单一内容对象,比如报表规范、进度表或数据包,另外还提供其他增强的维护功能。

验证内容并开始使用

初次加载生产环境之后,应当执行全面测试来验证所有报表都运行,且报表输出和时间符合预期。一旦向最终用户开放生产环境,就可以根据组织的现有策略按需测试随后的导入。

如果 QA 和生产环境是一样的或者非常匹配,验证部署似乎就是多余的。事实上,很少需要验证部署,尤其在环境一样时。但是,鉴于 QA 环境使用生产数据库的一个镜像,执行一些测试和验证是有必要的,特别是在初次加载生产环境之后。如果两个环境是单独安装的,就可能存在问题。配置文件、安全性和数据库客户端仅仅是会影响生产环境中的报表和数据包的一些方面。

不管环境之间如何相仿,对从 QA 到生产环境的部署和所有相关文件执行足够测试总是有必要的。验证部署的战略应当记录在案,且在每次导入部署时应当严格遵循。

实现任何必需的生产变更

可能会出现这样的情况,即在生产环境中出现问题,需要立即更改报表、安全性或环境配置。通常情况下所有变更应当通过环境遵循本文定义的流程进行迁移,这就需要在开发环境中做更改,将其迁移到 QA 环境进行全面测试,最后迁移到生产环境中。可能会存在一个生产影响问题,因为无法等待全面的部署流程完成而出现的问题。

例如,应用到报表的一个安全性问题可能允许用户查看比打算使用的更多的数据。报表对于管理团队很关键,因此不能脱机经过整个部署周期来实现必要的变更。在这样的情况下,可以在生产环境中执行修复,然后立即回滚到开发和 QA 环境中,以确保它们是后续的任何新部署的一部分。

生产内容的向后部署

虽然生产环境不适合专业的报表开发,但是用户创建即席报表的能力产生了从生产环境到开发环境进行内容的向后部署的潜在需要。可能会不时地创建即席报表,该报表可能对其他用户很有价值,且被应纳入常规的开发周期。在这种情况下,可以在生产环境中使用一个 Deployment 文件夹将即席报表部署回开发环境。然后可以在获准的开发位置处理报表,最后将其放在最终位置,以便展示给最终用户。也有可能出现报表保持原样的情况,因为它们是一个很好的起点即席或分析报表。

图 11 显示从用户的 My Folder 或 Public Folder 获取即席报表、然后移到 Deployment 文件夹的流程。然后将 Deployment 文件夹部署到开发环境,将报表移到开发位置。完成开发之后,将报表放在其最终演示位置上,此时就可以使用选择的部署方法准备将其部署到 QA 环境了。

图 11:将报表从生产环境位置移到 Deployment 文件夹,然后部署到 Development 环境,由报表创建者在开发位置增强之后,将其移动到最终演示位置上
图 11:将报表从生产环境位置移到 Deployment 文件夹,然后部署到 Development 环境,由报表创建者在开发位置增强之后,移到最终演示位置

也有些情况下,由于没有正确遵循变更管理流程,开发或 QA 环境与生产环境变得不一致。如果生产环境的内容是正确的,但其他环境的不正确,您可能希望将生产环境的内容(如数据包和报表)向后部署到其他环境中来替换其内容。


用户培训

总而言之,建议用户采取 IBM Cognos 讲师提供的正式培训,确保正确、充分地利用 IBM Cognos BI 工具。但是,它并不总是可行的,尤其是对于庞大的用户群。例如,您的组织可能有数百甚至上千个用户。他们的培训可能仅仅涉及到如何使用为其开发的 “预制” 报表。这种培训是特定于其业务和数据的。在这些情况下,可能需要内部培训。如果是这样,QA 环境通常就是进行这种培训的最佳地点,因为它与报表开发不冲突,且不引入风险到生产环境中。

应当安排培训和 QA 测试,让两个活动不冲突。

参考资料

学习

获得产品和技术

讨论

  • 参与 developerWorks 博客 并加入 developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=810377
ArticleTitle=IBM Cognos 最佳实践: IBM Cognos BI:在环境之间部署内容
publish-date=04262012