结果

在 Developer Plan 租户上开发和测试应用

检查点

  • 检查应用名是否在单个 manifest 文件中

  • 注意，必须为 manifest 文件中的每个应用名注册一个组件。组件必须与 manifest 文件中的相应名称匹配。

  • 检查是否已定义应用所使用的后端服务：

    • 在单个 manifest 文件中并且

    • 作为“Developer Cockpit”中的组件。

  • 检查 node.js 应用是否

    • 构建为包含所有相关项的版本

    • package.json 中的 version 是固定的而非可变的。
      如果应用配置了可变的 npm versions，则开发的应用和部署的应用之间可能会存在差异。这可视为代码库变更，将导致 CF/MindSphere 拒绝该应用。

准备移交给操作员

  • manifest 不应包含 HOST、DOMAIN 或 ROUTE 条目。这些条目已弃用。

  • 在 manifest 文件中配置构建包。自动检测并非在任何情况下均有效

  • 打包 Zip 文件之前，请检查 manifest 中的 PATH 条目是否与 Zip 文件夹结构类似。

  • Zip 文件中的文件夹应仅包含应用所需文件。无 .git 等文件夹。

  • 建议采用以下 Zip 文件结构。

    • /
      /component1/application file.jar
      /component2/application files
      /component2/css/css-files
      /component2/js/java-script files

    • Manifest 文件不应是 zip 的一部分。MindSphere 稍后会添加它。

  • 请注意，操作员将用相同的名称部署应用。因此，我们建议在 manifest 中使用随机 route

  • DNS 条目或主机名在 Cloud Foundry 中是全局唯一的。在不同的空间中，两个应用的 host 名称不能有任何相同之处。应用不应与硬编码的应用名称绑定。如果两个或多个操作员使用该应用，应用名称将会有所差异。

  • 对将要交付的 manifest 进行测试推送。失误或错误将导致操作员无法部署应用。此外，Siemens 正在对 manifest 进行测试。如果它无法正常工作，应用将被拒绝。

  • 您无法在操作员 cf org 中直接更新应用。应用中的每个更改都必须经过 Developer Cockpit。否则，应用将被拒绝并从系统中自动删除。

  • 每个应用的默认内存设置为 256MB。如果您的应用需要更多内存，请在 manifest 中进行定义。

  • 注册 Mindspace 网关后，在开发者 CF 空间中测试应用。即使该应用可在另一个 CF 环境中正常工作，也要进行测试。

  • 尽可能精确地定义组件端点。如果您有多个组件，/** 可能会产生负面影响。使用 /** 向网关发出信号，说明每次调用（GET、POST 等）都应路由到该端点。无法保证此端点为最后一个被调用的端点。在某些情况下，所有请求将只路由到此端点。因此，建议使用这些端点下的文件夹，例如 /html/** 或 /carcontrol/*

  • 后端服务无法通过 CF 空间共享。在 Developer Cockpit 中进行应用设计时应该考虑到这一点。如果两个应用需要相同的服务，那么它们应该属于同一个 MindSphere 应用。

  • 无法在一个空间中部署两个不同的应用。每个上传到 Mindsphere 供操作员使用的应用都需要空间。

  • 所有需要由操作员更改的环境 variables 都应进行记录。

  • 应用的“上传”使用验证最多需要 14 天。

移交给操作员

将应用分配给操作员是一个三向过程。

  1. 在“Developer Cockpit”中，将开发者租户的应用分配给操作员。

  2. 操作员在“Operator Cockpit”中确认移交。

  3. 开发者在“Developer Cockpit”中授权移交应用。

章节 2.1