|
级别: 中级 Anthony Bernal (abernal@us.ibm.com), 高级 IT 咨询专家, IBM Software Services for Lotus 2006 年 8 月 14 日 设计流程，并建立用于开发、构建和部署门户的环境。了解如何控制源代码和用于构建组件、管理持续集成和部署到测试环境的各种方法，以及如何部署生产发布程序包。了解相关最佳实践、可使用的工具和策略，以创建您自己的流程。 在创建新的门户系列的这一部分中，您将了解如何创建自己的流程，以便在 WebSphere Portal 环境中构建和部署代码组件。可以将不同的技术和产品集成到您能够管理的内聚系统中。
本文提供了一些最佳实践和通用信息，用于帮助您创建自己的流程。文中概略介绍了编译（或构建）代码、在门户框架内部署自定义门户应用程序的基本流程和相关基础设施。 那么，此讨论为什么重要呢？如果您进行过任何类型的 IT 或软件项目，就可能知道这个问题的答案；不过，为了清楚起见，我们将在此处说明其原因。 构建和部署流程可帮助确保以下事项：
虽然在本文中您还会了解到某项流程之所以重要的其他原因，但主要值得注意的方面如下：
这些因素是相互交错的；不过每个因素都会具有其独特的设计特点和挑战。理想的结果是，这些相关项能彼此协作，从而提供工作正常的门户来供客户使用。 最开始的时候，您可能看不到配备构建和部署流程的任何好处。事实上，可能看起来要进行大量的工作，要实现更多的结构和规则，但其回报却甚微。不要被暂时现象所迷惑，因为该流程的价值将可能很快就会体现出来。 例如，项目生命周期中的一个重要时期就是正式投入使用前的那段时间。基础设施已经就位，已将部分代码部署到环境中，且正在进行测试。在大多数环境中，会进行多种类型的测试，如：
其中的每种测试类型都可能导致开发团队根据反馈再进行一次开发循环，从而可能创建软件的新版本或错误修复程序。 而这正是很多项目出现错误的地方。随着不断创建各个组件的不同版本并需要对其进行部署和测试，能够在不同环境中快速构建、部署和测试就变得至关重要了。同样重要的是，需要知道每个环境中部署了每个组件的哪些版本以及测试的结果如何。 没有一个流程适合所有的情况。不同的组织需要采取不同的方法。团队组织结构、行政结构、代码存储库以及构建工具的选择都会影响您的流程的工作方式。您可以选择本文中提出的观点来设计自己的流程。 就本质而言，门户与其他 J2EE 项目并没有什么不同；不过，门户框架的确有一些限制和挑战。您需要确定如何设置项目以在 IDE 内最好地工作和支持一致的构建，还要确定如何将不同的组件部署到不同的环境中。 构建 Java 组件与大部分项目基本相同，特别是 J2EE 或服务器端组件更是如此。主要区别是会使用不同的库和 API，且需要对项目进行恰当的设置，以充分利用您的 IDE。 流 程的部署部分可以使用与部署非门户 Web 应用程序时不同的工具或方法。门户和 WebSphere Portal 环境要求进行额外的配置工作，而不仅是安装 Portlet 或组件。您需要考虑门户布局和访问控制问题；可以使用特定于 Websphere Portal 的 xmlaccess 命令进行配置、版本控制和部署工作。本文稍后将介绍有关这些注意事项的更多信息，另外还会提供一些可应用到您的项目构建和部署流程的技巧。
处 理开发、构建和部署问题时，需要考虑的问题的确全部都与流程相关。开发人员并不太喜欢存在大量流程，因为他们感觉到流程对其形成束缚，无法尽可能快速方便 地完成相应的工作。实际上，我们的目标是相同的；即，我们的目标是建立一个简单的、不会带来干扰的流程。这个方法是成功的关键，该流程应始终从开发人员角 度考虑问题。堆砌一些技术步骤或复杂步骤，并试图强制团队遵循这些步骤，这样的做法可能并不会非常有效。相反，应该提供一系列简单的步骤，在其中使用能集 成大家当前使用的一系列工具且能与之良好协作的工具。 除了流程定义外，还要创建开发标准和约定。我们将首先完成这项任务，然后进行流程定义，以提出一些您可能希望在自己的项目开发流程定义中加入的要点。 开 发标准提供一组可重用的常识性指导原则，开发人员在交付代码模块或组件时应该遵循这些指导原则。通过为项目定义一组初始标准和模板，可以向团队传达体系结 构、设计和实现指南。通过列出这些标准，还可确定开发人员在编写各种模块的代码时的预期行为。没有任何标准，或未在开发流程中包含任何初始想法，可能在部 署时或以后为各个模块提供支持时出现混乱。 定义标准时，您需要符合 WebSphere Portal 提供的框架。您需要知道和理解各种即时可用的功能，以确保您的设计将与 WebSphere Portal 协同工作——而不是对其造成阻碍。如果不熟悉 WebSphere Portal，这些简单的指导原则可在您开始首个门户应用程序时提供帮助。
由于每个项目彼此不同，各自的要求差异很大，因此您需要将标准定义与环境定义分离开来。即，创建一个独立的开发环境设置和配置 文档来说明具体的配置信息，并在构建环境过程中对其进行维护。其中包括以下信息：
不过，不要局限于项目或开发工作的标准。没有任何指导原则能处理可能遇到的所有情况。有时会遇到无法应用当前标准的情况。遇到这种情况时，请花一些时间深入分析一下情况，并进行以下工作。
要提高开发流程的标准化程度的原因很多。您可能已经遇到过需要复查或修改其他团队成员编写的代码的情况。即使是最好的程序员，测试、复查和调试不遵循任何标准的代码也是一项艰巨的任务。由于无法理解而剔除代码并重新编写的情况真是太多了。 遵循设计良好的编程标准能提高所交付的代码内的一致性，并能够提供更优质的代码，从而更便于其他开发人员理解和维护。设计良好且文档完善的代码可减少长期维护成本，还能减少将构件提供给其他团队或团队成员时的开销。 我们所指的关注点 分离阶段是指使用不同的环境控制组成部署发布版本的代码流和其他文件。保持不同环境彼此独立，且仅允许文件通过已定义的流程传播，可帮助确保构建流程中的各个关键要素，如控制、可重复性和可靠性。 图 1 显示了开发工作站和最终生产环境之间的代码流，我们以此来说明关注点分离的概念。如果您能理解这个流和环境分离，则可以在构建和部署流程进行期间对环境进行有效控制。 大 部分开发人员都在自己的本地工作站上工作。过去数年一直是这样，目前并没有需要改变这种方法的切实理由。当目标环境是 WebSphere Portal 时，使用 Rational Application Developer for WebSphere 及其 Portal Test Environment 的开发人员的效率会非常高。这些工具的设置过程非常简单。还可以考虑使用包含目标环境的开发映像。这将允许编程人员在环境被破坏时进行重置。 在某些情况下，开发人员可能需要在自己的开发工作站上有完整的门户安装；例如，您可能希望使用正确的目录服务器 (LDAP) 和数据库来反映生产中使用的组件。构建安全组件的开发人员需要在其开发环境中设置与生产环境中类似的安全机制。 有些团队对独立构建服务器和独立开发集成与测试的需求不甚明了。事实上，没有硬性指导原则规定如何使用这些环境。我们将告诉您一种方法和这方面的相关建议，但您可以使用自己的策略来管理这些环境。 主 要的想法是将构建（或编译）和打包软件的流程从开发人员的工作台分离出来。通常，构建服务器将是一台物理计算机，但不是任何开发人员的工作站。不过，在小 型环境中，构建服务器也可以是位于开发人员工作站上的一个逻辑独立体。关键是，要确保所有进入构建流程的组件都来自版本控制，而不是来自其他工作站或计算 机，以便确保每个构建操作都能从相同的单一源重复。 我们建议您严格执行这个实践。建立了此流程后，在出现构建操作时，通过源控制更新最新代码或缺失的 jar 只需要很少的时间。 对开发集成环境采用类似的方法。除了通过 SCM 或构建存储库外，不应将任何代码部署到此计算机上。开发人员需要访问此计算机来检查日志和查看结果；不过，永远都不应该允许他们部署自己的代码，因为这样会导致以下问题：
团队对此方法的一个可能的担心是，对环境施加约束可能会减缓开发团队的工作进度。若要解决此问题，可以允许部分或全部开发人员在其本地工作站上安装完整的门户基础设施，或者简化构建流程来包含持续集成和部署，以便能自动构建和部署组件。 发 布环境绝对远离大部分团队成员，不过部署和配置有这样的需求时除外。通常需要多发布环境来避免进行多项测试工作时环境间出现冲突。质量保证 （Quality Assurance，QA）、用户接受度测试（User Acceptance Testing，UAT）、性能和压力测试都可能带来需要进行评估的问题。 由于禁止开发人员访问这些环境，因此需要采用某种方法来允许开发人员在不同的计算机上查看和配置日志，以便能够进行问题诊断。可以向特定用户授予有限访问权限。或者，可以允许在不同计算机上通过网页访问某些日志和属性文件。 开发负责人应自己（或指定某人）控制源代码管理流程，这样才是团队管理流程，而不是流程管理团队。此人要确保签入所有代码，并已准备好进行构建和部署步骤。通过使用并理解组成当前代码库的所有组件，此人可以和其他团队就组件如何一起工作以及如何部署进行沟通。
在 很多 WebSphere Portal 项目计划中，“构建”通常被标识为项目计划上的单条线或任务。在有些项目计划中，甚至不将构建定义为任务，因为有些项目经理将其视为开发人员的日常工作的 一部分。构建是为门户项目创建门户构件的过程。WebSphere Portal 最佳实践认为，构建流程是门户项目的发布周期中一项重要的活动。 WebSphere Portal 既是应用服务器，也是应用程序框架。它允许开发人员创建自己的代码（针对此框架进行了自定义）并将代码部署到 WebSphere Portal，以创建一个新门户网站。构建流程会对代码进行编译并生成可部署程序包（其中包含 WebSphere Portal 项目解决方案构件）。 通 过定义构建流程，可确保每次团队生成可部署程序包时，将在正确的级别进行组合，流程能以完全相同的方式进行。整个构建流程应该是可重复的和可跟踪的。尽可 能详细地对构建流程中的确切步骤顺序进行确定、记录和自动化。由于构建流程在较大的门户项目中会变得比较复杂，因此更有必要实现这样的标准化。 明确定义的构建流程可帮助消除开发、集成、过渡和生产环境间潜在的差距。您可以使用构建流程来将门户构件从一个环境迁移到另一个环境。它还可以消除与编译、类路径或属性相关的很多问题；这些问题可能会耗费大量的项目时间和资金。 您可以定义两种类型的构建流程：
创建构建流程涉及到以下活动：
在很多门户项目中，开发团队仅由代码开发人员组成。在接近开发阶段尾声时，开发人员将创建 Ant 或 Maven 脚本来编译代码，并生成门户构件（如 Portlet 的 war 文件和主题和皮肤的 zip 文件）。 您可以指定团队中两个人分别担任构建管理人员（或代码维护人员）和部署管理人员（或发布管理人员）。对于大型门户项目，构建管理人员和部署管理人员都是开发团队中非常重要的角色。根据项目的规模不同，可以让一个人同时担任这两个角色。 构建管理人员负责维护代码，运行构建流程，还要确保每次使用完全相同的步骤生成门户构件。
良 好的构建流程应定义要生成哪些构件。这些构件可以为组件（如 war 文件或 zip 文件），也可以为 wps.ear 包中的文件。为了确定一个构建流程来生成这些不同类型的构件，需要对您的门户解决方案的设计进行仔细的研究。构建 Portlet 的方式可能会与构建门户可能需要的其他构件的方式不同。请参见“下载”部分，其中提供了使用 Rational Application Developer 项目结构来构建 Portlet 的 Maven 和 Ant 示例脚本。 开发团队完成了其代码开发工作后，构建管理人员将与开发团队和部署团队密切合作，以生成门户构件并将其部署到门户环境中。构建管理人员将运行构建流程来生成门户构件，部署管理人员则将这些构件部署到开发、集成、过渡和生产环境中。 当开发团队希望将其新代码部署到开发环境中时，会向构建管理人员发送构建请求。此构建请求指定以下内容：
如图 2 中所示：
随着开发工作逐渐接近门户测试阶段，构建管理人员可以创建每日构建并将构件部署到开发人员的开发环境中。构建管理人员应该每周（或更频繁）对更为成熟的标记代码进行相同的工作，将其部署到测试人员的集成环境中。 由 于存在很多选择，选择构建工具也可能成为一个比较麻烦的任务。可以选择各种开放源代码工具，如 Ant、Maven 或构建服务器的 Cruise Control。这些都是 Apache 的开放源代码项目。为了给环境选取正确的工具，将需要进行一定的研究工作；在很多情况下，这些工具可以协同工作，从而提供额外的功能。 以下是 Julien Dubois 在“Master and Commander”一文中所做的一个简单比较。
Ant 可为您提供灵活性，而 Maven 则可提供更多的结构和良好的依赖关系管理。可以在 Ant 内使用部分 Maven 功能，反之亦然。 可以将 Ant 或 Maven 与 CruiseControl 结合使用，从而实现构建过程的自动化。如果有 Ant，则可以从 Maven 调用 Ant。可通过一些任务从 Ant 使用 Maven 功能，反之亦然。 CruiseControl 允许对构建进行计划安排——可以在夜间或任何特定时间进行。因此可以节约一定时间，特别在构建需求更频繁的项目初始阶段更是如此。这是一个用于持续构建流程的框架。通过使用 CruiseControl，可以进行以下工作：
的 AntHill 是使用 Ant 的另一个构建工具（需要缴纳少量许可费用），非常易于安装和使用。 以下是在创建构建和部署脚本时要考虑的一些构件。
为了提供可跟踪性和故障转移恢复，在将门户构件放入部署区域后，还应该将其作为 新版本保存到 SCM 中。您可以从 SCM 内跟踪这些门户构件的构建历史。 您要进行的最重要决策之一就是，您的团队将使用哪个源代码管理系统。有很多系统可用，您的组织或公司标准可能会规定使用哪个系统。 有两种完全不同的源代码管理系统。
CVS 或 Concurrent Versioning System 是一个可行的选择，特别在没有其他 SCM 系统供团队使用时更是如此。CVS 是免费提供的开放源代码系统，在开发领域得到了广泛的接受和使用。管理人员可能遇到的一个潜在缺陷是 CVS 内缺乏文件锁定功能。根据您的观点或管理风格不同，既可以将其视为优点，也可以将其视为缺陷。对于能有效沟通、组织良好的团队，缺少锁定不是问题。 另一个可能的问题是，由于 CVS 并未由某个公司在市场上正式销售，因此缺少正式的支持服务。这可以作为不选择此工具的一个有效理由；不过，由于开放源代码社区广泛使用此工具，因此能为您遇到的很多问题提供强大的技术支持。 按 照开发社区推荐的方式使用 CVS 还可帮助缓解各种问题。使用 CVS 的优势之一在于其提供了一些免费的外接程序工具。例如，CVSWeb 是基于 Web 的接口，允许非 CVS 用户直接查看存储库，而无需使用客户机软件或开发环境的插件（将在下面进行说明）。 下面的图 5 显示了如何将 CVS 集成到您的 Eclipse 或 RAD 开发环境中。
随 Rational Application 安装了一个功能齐全的 CVS 插件。可以在 RAD 的 Team 透视图中时设置此插件，这将允许开发人员在进行开发时方便地查看、提取和合并代码段。这个功能对于定义良好且易于使用的构建和部署流程非常重要。当向开发 人员提供了简单的 SCM 集成流程时，就会减少他们尝试走捷径的可能性，从而避免打乱团队的流程和控制。 并不能保证每个构建都会完全成功。构建工具执行后，构建管理人员将查看构建工具日志文件，以确定构建过程是否完全成功。如果构建失败，则要尝试确定失败的原因。大部分构建工具允许将构建报告以电子邮件的方式发送出去。 如果失败是由于源代码导致的，构建管理人员可以向开发团队或负责修复构建的人员发送请求。开发团队修复了代码后，构建管理人员将重新运行构建流程。将重复此过程，直到构建完全成功为止。 在某些情况下，可能需要向构建构件应用紧急修补程序，以便能继续进行测试或保证按时投入生产环境。将紧急修复流程作为构建流程文档的一部分清楚地进行记录。 总的说来，构建流程是门户项目发布周期中的一个重要活动。构建管理人员应是开发团队中的成员。应对构建流程进行定义，并应选择（或创建）构建工具来实现流程的自动化。 如果团队遵循所定义的构建流程，并使用构建工具进行标准化，则可以避免很多来自构建流程的意外问题。在构建流程上花费的时间和资金将通过消除测试期间的其他意外问题而得到回报。
在 很大程度上，门户是一个复杂的 J2EE 应用程序，其中可以包括 Web 模块、ear 文件、jar、属性文件和其他资产。每个 Portlet 都是一个实现特定功能的独立 Web 应用程序，可以作为独立的单元进行操作。通过进行恰当的设计，可以将这些 Portlet 组合为组合应用程序。 在很多情况下，由于 WebSphere Portal 提供了额外的框架，而使得门户环境甚至会比类似的 J2EE 环境还要复杂。您需要在门户数据库中注册某些特定于门户的组件，以便能够对其进行管理，并向环境提供。 WPS.ear 是核心 WebSphere Portal 包，作为 Web 容器中的独立 Web 应用程序运行。其中包含门户的大部分基本功能，包括一些重要的集成功能，如菜单和外观。 可 以采用多种方式安装 Portlet，如使用门户管理界面或使用 XML Access。由于最终的目标是实现部署门户资源和组件的流程的自动化，因此需要采用脚本对其进行部署。您可以对 Portlet 进行分析，并基于 Portlet 内的 portlet.xml 文件生成 XMLAccess 部署脚本。 请参见 Reference: Sample XML configuration files section of the WebSphere Portal InfoCenter 中提供的大量示例脚本。您可以选择并修改适合您的部署需求的脚本。 然后，可以使用经过修改的脚本来安装 .war 文件。不过，您还需要使用某个自动化方案来构建和部署此脚本。为了自动生成 Portlet，您可以使用清单 1 中的脚本，同时通过自定义 Ant 任务检查 portlet.xml 并使用一些模板属性对其进行更新。
可以通过此示例来将 Portlet 的名称替换为每个构建的版本号。在测试期间，开发人员和测试人员可以使用这个强大的方法来确定其正在使用的版本。此示例包含构建的时间戳，以便确定其创建时间。 清单 2. 用于使用版本号替换 Portlet 名称的示例模板
此模板属性文件相当简单，只是一个希望在筛选操作期间替换的属性列表。还可以使用 Ant 脚本安装 Portlet。 清单 3. Ant 示例部署脚本
此示例调用 XmlAccess 类，并同时传入所需的参数。用于更新 Portlet 的 xml 文件应随 Portlet 一起提供，可以作为版本控制的一部分进行保存。 可以将 WPS.war 文件作为 .ear 文件部署到服务器。通过这样的方式部署主题和皮肤比直接将其复制到服务器更为安全。 门户主题是基于 JSP 和 CSS 文件结构的文件系统。创建门户主题首先要理解其文件系统。WPS.ear 是 WebSphere Application Server 下的一个企业应用程序，因此您可以在与以下所示类似的服务器文件系统中找到该文件： [was-root]/installedApps/wps.ear
在此文件系统中，可以找到 themes 和 skins 文件夹，这两个文件夹下均包含有 markups 文件夹。 之所以作为 EAR 部署，主要是为了跨系统实现源代码控制、可重复性和一致性。建立了系统后，可以更方便地在部署期间执行此步骤。 可以采用若干其他方法部署 EJB：
有关安装 ear 文件的基本脚本方法，可以使用以下命令：
./wsadmin.sh -user USER -password PASSWORD -c "\$AdminApp install
/usr/WebSphere/AppServer/installableApps/wps.ear {-update -appname
wps.ear}"
此命令将安装 wps.ear 文件。 您将在下面的部分中了解关于此方法的更多信息。 按 照传统的做法，希望提高性能的网站会将静态文件移动到 Web 服务器层，以减少应用服务器上的负载。虽然这个做法不错，但对于尝试以这种方式构建应用程序的开发人员却有些困难。Web 服务器插件包含内置 ESI 处理器，该处理器将缓存整个页以及必要的片段，具有较高的缓存命中率。可以将静态文件和 Portlet 打包到一起，同时仍然能够获得将其移动到 HTTP 服务器时的性能优势。ESI 处理器实现的缓存是内存内缓存。可以通过 WebSphere Web 服务器插件配置文件 plugin-cfg.xml 对此缓存处理器进行配置。
对 于最初发布的 WebSphere Portal V5，将组件部署到集群环境需要执行若干步骤。由于 XMLAccess 更新门户数据库的方式，如果仅在多个可能位置中的一个位置更新代码，集群环境中可能会出现冲突问题。很多生产环境都优先采用集群方法来提供更高的性能和服 务器出现故障时的故障转移功能。WebSphere Portal 的后续版本和修复程序包已修复了其中的一些问题。在本文中，我们假定部署流中出现了最糟糕的情况，以便能涵盖所有需求。 使用 XMLAccess 安装或更新 WAR 文件。
运行经过修改的脚本时（完成了初始部署和同步后），门户将激活系统上的所有 Portlet 并进行必要的页面填充操作。 在 集群环境中，必须从 Deployment Manager 导出门户 EAR 文件，使用新主题和皮肤目录更新 EAR 文件，然后将企业应用程序文件重新导入到 Deployment Manager 计算单元。如果您使用的是独立门户服务器，则请使用应用服务器代替 Deployment Manager。有关详细信息，请参见 InfoCenter under Deploying customized themes and skins。 可以使用共享库在门户内不同组件或 Portlet 间共享资源。这些共享库通常是在应用程序设计阶段确定的（在此阶段确定需要跨多个 Portlet 或组件共享哪些组件）。使用共享库时，您需要在应用服务器内设置变量，以允许在必要时加载这些共享库。 要部署共享库，请执行下列操作：
或者，将 .jar 文件直接放入 /PortalServer/shared/app 目录。如果要为这些文件使用独立目录，则请使用管理控制台或 wsadmin 配置命令在服务器中创建共享库，例如：
缩 短站点的停机时间是一个常见问题；不过，计划的维护停机时间却是一件必要的“坏事”。管理人员理解了这一点后，一切就会变得更加简单了。站点可能没有计划 停机；不过，可能会因此招致大量硬件投资，因为您需要准备两套基础设施，以便在升级一套系统的同时另一套系统能继续保持所需的用户负载处理水平。 如果您的组织不准备承担高标准基础设施的相关成本，则现在务必与管理人员和最终用户交流或讨论对计划停机的需求，使其在投入使用后成为一项日常事务。 如果流程设计良好，且团队工作同步，则经常可以将停机时间降到最低水平。可能会因为若干原因需要停机：
在有些情况下，会在维护期间同时进行上述两项工作。如果您有多个发布环境，就可以在预生产环境中进行维护工作，以尽可能减少生产部署期间的风险。
发布会涉及到能在门户中部署和配置的各种各样的构件。发布版本可以是配置更改、Portlet 更新、用于安装新门户的完整程序包和任何更改组合。团队间的沟通和跟踪对成功维护组织中的每个环境非常关键。 发 布版本具有编号，通常的形式为主版本、次版本、修复程序编号并加上点号，如 2.1.0.1。这些数字可能表示主版本、次版本和版本内不同类型的修复程序。您将需要对这些发布版本进行记录；包括版本中包含的内容以及部署说明。您需 要跟踪发布版本在以下每个环境中的情况：开发、集成、操作接受度测试、用户接受度测试、过渡和生产环境。 在发布计划中，请确保包含维护窗口、备份、部署时间、搁置时间和测试的相关内容。请自动化安装，以尽可能减少人为错误；请包含数据库更新、访问控制、皮肤、主题和页面更新。
经过全面测试的备份和恢复过程对任何生产环境都十分重要。WebSphere Portal 也不例外。请开发并测试（在测试环境中进行）完整的灾难恢复策略和方法。经过验证后，应将这些过程实现到 WebSphere Portal 生产环境中。 虽然这些不是用于备份和恢复的详细过程，但提供了进行 WebSphere Portal 备份和恢复的一种方法，可以与公司现有的灾难恢复过程一起实现。 从 失败的部署回滚，或者新代码存在问题，都会使得使用者面临一定的困难。利用一些 WebSphere Portal 功能可简化出错时应进行的工作。由于遵循的是以前发布版本的已定义构建和部署流程，最简单的“回滚”方法就是重新部署上一个发布版本。这可能并不总是最简 洁的方法，但对于大部分情况，这将确保在门户中重新安装最新的有效代码包。 目前，确保全面回滚能力的唯一方法是在部署前进行完整的文件系统和数据库备份。这将确保文件系统的正确性和恢复数据库备份中任何新的配置更改。还可以在 XML 脚本中使用“事务性”来确保脚本以“All or Nothing”模式运行。
本文提供了有关为门户项目创建构建和部署流程的观点和建议步骤。本文的主要目的在于让您认识到，对此流程进行考虑是非常值得的。我们刻意在较高的抽象层次进行讨论，让您自己确定适合自己的环境的相关细节。我们专门提供了一些示例和脚本，以帮助您尽快上手。 请 牢记所讨论的这一过程中使用的一些指导原则。保持简单，并在项目中尽早开始相关工作。即使不会立即构建任何东西，也请启动脚本并持续运行，直到其正常工作 为止。脚本必须随着项目的进行而持续加以改进，只有这样，才不会在项目结束时发现有一大堆让人生畏的创建任务需要完成。如果没有配备构建服务器，可以进行 简单的脚本测试，提取必要的代码组件来运行脚本。如果脚本不能正常运行，则可能相对路径存在问题，需要进行修复。最后，不要尝试设计一个执行您认为需要完 成的所有任务的流程。让系统随着您的需求逐渐发展，而不要尝试立即形成整个流程。 本文并没有详细讨论整个构建、部署和迁移流程 (这对项目的成功非常必要)。例如，我们并未讨论如何在门户内构建和传输页面和 Portlet 布局。此步骤之所以重要，是因为您并不一定希望管理员在不进行更为正式的 QA 和性能测试流程来确定任何更改的影响的情况下在生产环境中更改布局。具有针对所有组件的发布策略可让您快速从环境内可能出现的异常情况中恢复。
学习
获得产品和技术
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
