Publishing an app
When the application logic has been developed and tested, the final step in the development flow is to publish it. Publishing (also called "releasing" or "deploying") means that the application is uploaded to the VIKTOR platform, making the app available in the organization environment. Note that the source code is secure and cannot be inspected by users that have access to the online VIKTOR environment.
Free VIKTOR developers (cloud.viktor.ai
) can only publish editor-type apps with a
public visibility on the workspace.
Publish a new app
Publishing an app requires a handshake between environment admin and the developer (which may be the same person):
- Creating a new application (developer)
- Publish the application source code (developer)
- Creating a new workspace (environment admin)
Free VIKTOR developers (cloud.viktor.ai
) automatically have environment admin rights.
Before an app can be published, it needs to be prepared in the online VIKTOR environment by the developer. Please refer
to the workspace and apps documentation to see how to create an app.
When this is done, the developer is enabled to perform step 2 by using the
publish
command of the CLI:
viktor-cli publish --registered-name <insert-app-name-here> --tag v0.1.0
- Although we use the term 'tag' as a variable for the publish command, this is not linked to the git tag. The CLI
will not check out the tag you specify in the publish command, you will have to do this manually first (e.g.
git checkout <TAG>
). - If you are using git the CLI respects the .gitignore file and uses git to gather the files for uploading to VIKTOR.
- You can force the CLI to upload all files in the app folder by using the
--use-filesystem
flag. - If you have any uncommitted changes or unstaged files, the
publish
command will fail as a safety mechanism.
The registered-name
is specified in step 1 by the developer and can be inspected using the
apps
command of the CLI:
>>> viktor-cli apps
Name | Full name | Latest tag | SDK version | Status
calculate-foundations | calculate-foundations.viktor.company | - | | created
cost-calculator | cost-calculator.viktor.company | v1.2 | 13.3.0 | published
compare-cpts | compare-cpts.viktor.company | v8.6 | 13.7.1 | published
...
or in the interface in the "Apps" menu:
After pressing enter you will see a spinner which you can use to monitor the publication. Once you see the spinner it is not possible to cancel the process. It is not a problem if you accidentally close the CLI at this point, publishing will continue in the background. During publication several checks will be performed. If any problems occur you will be presented with the reason for failure. Please contact VIKTOR in case you are stuck.
When successful, the environment admin can create a workspace in the organization environment. This workspace can subsequently be visited by users that have access to it. See workspace and apps for more detail.
Publish a new version of an existing app
Every new addition or change to the application source code requires a new release, which is done by directly publishing the source code as described in step 3 in the section above. Publishing a new version can be automated using Continuous Deployment (CD) tools.
Make sure to keep backward compatibility in mind when creating new releases.
In case of an entity type incompatible publish, follow these steps:
- Use the
publish
command with the new app code - Wait for it to fail due to the incompatible change
- Notify your contact person at VIKTOR (or send a message to support@viktor.ai) and mention the incompatible change(s)
- Await VIKTOR to republish with necessary adjustments in the database
Limitations
The following cases cannot be handled without intervention from VIKTOR. If you want to publish an app and encounter one of these limitations, please reach out to your contact person at VIKTOR to publish the application.
- It is not possible to clear the database of an app before publishing.
- It is not possible to publish an app that has incompatible entity type changes, e.g:
- Removal / renaming of entity types that are already present in the database
- Changing names of top-level entities