Application handover

Application handover is the process of transferring new or updated applications to a MindAccess Operator Plan Account.

You decide the application you want to make available for productive deployment by uploading it together with additional information to an intermediate Application Repository.

The transfer process cannot be withdrawn after the upload. You are notified via "Developer Cockpit" and via email once the transfer of your application has been successful and the application is available to run on the MindAccess Operator Plan Account.

Preparation for handover

The handover is a threefold process consisting of the following phases:

  1. Prepare application upload.

    This is usually done by the developers.

  2. Approve application upload.

    This is done by the Developer Admin.

  3. Assign the successfully uploaded application to an operator.

The application must be uploaded as a single zipped archive. You need to use a single Cloud Foundry "manifest.yml” that contains the configuration of all Cloud Foundry applications that are from your application.

NOTE

Please use only zip-Archives and not any other compression algorithms for bundling your applications.

States of handover

In "Dashboard" for Cloud Foundry and self hosted applications:

  • In-Development: The first state is the application being in the "In-Development" phase. An application will move to this phase after its creation. The application needs to be then registered.

  • Preparation in progress: This is the second phase of the process. After pushing the binaries into the application, the application moves to the state of initiating the upload.

  • Waiting for approval: This is the third phase of the application handover. An application reaches this phase when its metadata information is submitted successfully.

  • Check in progress: This is the last successful phase before pushing the application to the "Promoted Apps" tab. After an application is ready for its upload, Developer Cockpit submits its requirements for getting approval from the administrator of the requested service plans. You can successfully submit the application for approval only if the application has one role and one scope added in it. The application moves for its validation.

  • Check failed: An application goes to this state if it fails due to mis match in its internal meta data uploads.

In "Promoted Apps" for Cloud Foundry and self hosted applications:

  • Ready for assignment: If the validation of the submitted application is approved, the application is pushed to the "Promoted Apps" with is new state. The application is now ready to be assigned to operators.

In "Promoted Apps", only for Cloud Foundry applications:

  • Remediation required: If a Cloud Foundry application does not have the matching binaries, metadata or manifest files with the Operator Cockpit metadata, the application goes into the "Remediation required" state. This suggests that the application has been rejected from moving for further processing and either requires a fix or needs to be removed from Developer Cockpit. However, the same application can be created again but the version number needs to be different.

    The application can also fail during the MindSphere production readiness validation process. The validation process starts after the "Check in progress" state.

Backend:

  • Deprecated: Application goes into this state if it faces any vulnerabilities when it goes for checks after the "Remediation required" state. But this is only valid for Cloud Foundry applications. Self hosted applications do not pass through any validations to be pushed to "Deprecated" state.

    However, this state visibility is not provided for front end users. If an application moves from "Remediation required" to "Deprecated" state, the communications are done backend via emails. Further courses of actions are decided backend.