Windchill Navigate 构建的部署过程
在部署过程中，需要通过各种环境提交和升级包。目的是在进入最终部署环境之前，在各个阶段对包进行全面的测试和验证。
Windchill Navigate 的部署过程包括以下步骤：
1. 在低层级环境中进行初始部署
2. 成熟度曲线阶段
3. 在生产环境中进行最终部署
假设以下场景：您的团队根据当前需求选择一个用例，然后将该用例集成到冲刺周期中。在该过程中，需要通过各个阶段提交和升级包。最初，通过在低层级环境中提交包来部署包。包将在成熟度曲线阶段升级。最终升级在最终部署阶段进行。
详细过程说明
1. 首次/初始构建部署 - PTC 从客户处收到的初始构建部署要经过 PTC 团队的全面审阅。此审阅所需的构件如下：
◦ 填写完整的问卷：由客户填写的详细问卷。
◦ 构建包：由客户/系统集成者提交的压缩包。
 | 初始构建只有在获得 PTC 团队的审批后才能进入下一步，以确保其符合所需的指导原则。 |
2. 成熟度曲线阶段 - 此阶段不需要获得 PTC 团队的审批。在此阶段，构建会经历成熟度曲线，具体包括以下任务：
◦ 错误修复：发现和解决问题。
◦ 逻辑变更：完善构建的功能。
◦ 用户验收测试 (UAT)：确保构建满足用户需求。
◦ 外观变更：调整用户界面，改善用户体验。
初始部署在非生产环境中进行。客户或系统集成商负责维护对构建所做全部变更的完整文档。
| | 在此过程中，由构建包和构建依赖项 (在第三方库中) 解决的需求保持不变，这一点至关重要。如有变更，必须重新启动部署过程。 |
3. 在生产环境中进行最终构建部署 - 由 PTC 团队全面审阅在产品服务器上进行的最终部署。此审阅可确保在将构建发布到生产环境之前，其所有方面都符合质量、功能和合规性的最高标准。此审阅所需的构件如下：
◦ 填写完整的问卷：由客户填写的详细问卷。
◦ 构建包：由客户/系统集成者提交的压缩包。
◦ 详细文档：成熟阶段对构建所做全部变更的完整文档。有关详情，请参阅“创建完整文档：关键指导原则”部分。
| | 此阶段需要获得 PTC 团队的审批。 |
客户指导原则
• 需求的一致性 - 您上传的初始构建必须包含全部重要内容。对于系统集成者而言，在第一阶段和第三阶段这两个部署阶段中，避免对需求或依赖项 (尤其是对第三方库) 进行重大变更，这一点至关重要。
• 详尽的文档 - 必须维护对构建所做全部修改的完整文档。
• PTC 团队审阅 - PTC 团队会在升级构建以在生产环境中进行最终部署之前，审阅您所做的全部变更。
遵循这些指导原则，可以确保 Windchill Navigate 构建的部署过程安全稳定。
部署过程应重复的频次
在考虑自定义时，您需要有明确的用例，且开发团队将按冲刺周期进行开发。您的团队选择一个用例 (可以是一个需求，也可以是一组需求)，并开始按冲刺周期进行开发。有时，可能需要多个冲刺周期来准备构建。
例如，在为期六个月的发布周期中所含的五个冲刺中，选择需求并进行开发。您可能有不同的时间表，例如为期 20 天的冲刺周期，其中包括开发、QA 和部署阶段。如果需求在冲刺周期内发生重大变更，必须重新启动该过程，且需要审批。
部署过程的频次取决于用例数和冲刺周期数。例如，如果要在 10 个冲刺周期内开发 10 个用例，需执行该过程 10 次。如果要在 1 个冲刺周期内开发 5 个用例，需执行该过程 2 次。
其他示例：
1. 示例 1：短期的冲刺周期
◦ 您有一个为期 2 周的冲刺周期。选择一个需求，花 10 天时间进行开发，花 2 天时间进行 QA，然后进行部署。如果您有 6 个需求，您需要在 12 周内执行该过程 6 次。
2. 示例 2：重叠的需求
◦ 您的重叠需求跨多个冲刺。例如，如果一个需求需要 3 个冲刺才能完成，将针对每个冲刺分别执行一次该过程，从而实现持续集成和测试。
3. 示例 3：周期中期的重大变更
◦ 如果在冲刺周期的中期对需求进行了重大变更，例如更改了数据模型，必须重新启动该过程。这样可确保重新评估所有依赖项，并获得审批。
4. 示例 4：频繁部署
◦ 您优先考虑频繁部署，冲刺周期为期 1 周。其中 4 天用于开发，1 天用于 QA，最后一天用于部署。如果您有 8 个需求，您需要在 8 周内执行该过程 8 次。
5. 示例 5：自定义时间表
◦ 可以根据项目需要，制定自定义时间表。例如，冲刺周期可能为 30 天，其中 20 天用于开发、5 天用于 QA，5 天用于部署。可以根据需求数量及其复杂性调整该过程的频次。
问卷中包含的信息
在部署过程中，必须填写两份问卷：
1. 初始部署问卷 - 在低层级环境进行初始部署时，需要填写此问卷。这样可确保在继续后续工作之前，所有初步检查和配置工作均已就绪。
2. 最终部署问卷 - 在生产环境中进行最终部署时，需要填写此问卷。此举旨在验证是否所有关键方面均已通过审阅和审批，从而确保部署过程平稳顺利进行。
问卷示例如下：
问题 | 答案 | |
|---|---|---|
一般详情 | 您的客户帐户名称 | |
您的 Windchill 版本 | ||
您的 Windchill Navigate 版本 | ||
您的计划部署日期 | ||
您的计划部署环境 | ||
包详情 | 您是否在低层级环境中测试过此包? (如果是，请命名环境) | |
您实施了哪些类型的自定义? | ||
此包中是否使用了第三方库? | ||
您使用的是默认身份验证方法，还是此包依赖于应用程序密钥? | ||
此自定义旨在实现什么样的业务用例或目标? | ||
您是否确定自定义的所有部分都不违反安全护栏? | ||
旧包与新包 (如有) 之间存在哪些差异? |
| | 在此问卷中，您需要说明新旧包之间的差异。例如，您可以解释是否添加了新功能、是否修复了任何错误或是否更改了版本号。这些差异很重要，因为它们有助于确保参与部署过程的每个人都了解变更内容。这样可以防止出现问题，确保兼容性，同时确保新包满足所有需求。 |
创建完整文档：关键指导原则
在提交最终构建以在生产环境中进行部署时，请务必提供在成熟阶段所做全部变更的完整文档。本文档应详细说明整个开发过程中执行的每一次更新、功能添加、错误修复和修订。
提供详尽的文档，确保所有项目干系人都知晓这些变更，这样有助于排除故障、保持一致性并验证构建是否满足所有需求。这一步对于平稳顺利进行部署过程至关重要，能够最大限度地降低错误风险，确保生产环境已全面就绪，可供新构建使用。
假设以下场景：
通常，从 1.0 版本开始构建周期。在后续阶段修订该构建时，您可能会将其更新为 1.1、1.2 等版本。准备好在生产服务器上部署该构建时，该构建可能已经过多次修订，达到最终版本，比如 1.7 版本。
应保留每次修订期间所做变更的详细记录。例如，如果您更改了 5 个项，应清楚地记录这些变更。此文档可以采用发行说明的形式，其大小因产品而异。
例如，此文档可以包括：
• 1.4.6 版本：增加了修复功能来处理特定问题。
• 1.4.5 版本：实现了新功能。
• 1.4.4 版本：改进了特定功能的性能。
此类文档有助于跟踪从 1.0 版本到 1.7 版本的构建历程。您可以使用屏幕截图或任何最能传达相关信息的格式。关键是确保实现全面的变更跟踪。可以根据个人需求设计格式，无论是 Word 文档、Excel 工作表还是任何其他方法。
变更日志示例如下：
示例 1 - 简明变更日志：单行摘要信息，供快速参考
示例 2 - 详尽变更日志：完整更新列表
示例 3 - 完整变更日志：更新、修复和改进内容/功能的详尽汇编
