Now that you've started building apps in Kuali, as a best practice we recommend testing and verifying that the form works as desired before publishing to your end users. Below outlines how to test your app and some best practices and approaches on how to roll out a new app to your institution.
How to Test an App Before Publishing
Kuali allows you to test your app and workflow while you build it via the Draft Mode option before you publish - this is true when creating new apps or updating existing. Within the Form itself, you can use the Design/Preview toggle to switch between editing the form (Design) and what it will look like to the end user (Preview):
You can also test the entire form lifecycle with workflow via the Design/Test toggle in the Workflow tab:
The Publish screen will run a validation check on the app to verify if all workflow steps are configured with valid parameters and that any form fields referred to in the workflow are present in the form. If any errors are found, they will be listed and it will prevent publishing until they are resolved. This helps to prevents you from publishing an app that may not function correctly.
More information on using these options can be found in the below articles:
New App Deployment Strategies
Depending on your use case, or the level of verification/testing you want to perform, you can handle new app verification and deployment in a couple of different ways when initially going live:
Test Using Draft Mode
As mentioned above, you can verify the form and workflow of an app via Draft Mode and the Workflow Simulator tools before you publish. If you feel confident it's behaving the way you desire, then you can assign the necessary permissions for the app and then publish - please refer to the Publishing an App and App Permissions articles for more information.
Test By Publishing and Sharing to only a Subset of Users
You can perform additional verification of an app with a subset of users to see how it will behave when creating documents, submitting into workflow, managing the Document List, etc. after you publish. This may allow you to work out some scenarios or test cases that weren't apparent when using Draft Mode. This may also be beneficial if your workflow includes integrations that are sending data externally and you want to confirm it's posting as expected.
This will require you to set the permissions of the app to only a subset of users that will be participating in the pilot testing/verification and then publish - please refer to the Publishing an App and App Permissions articles for more information.
Once you complete your verification and are ready to go live with the app to end users, you can publish in one of two ways:
- Copy the App, then Publish:
-
You can simply duplicate the app you verified (see the How Do I Create, Duplicate and Delete an App? article). This will copy over the verified form/workflow but not any existing documents that were created during verification. Once you set the appropriate App Permissions, update workflow steps if changed for testing, and Publish you can then go back and delete the original app you used for verification. This method would be our best practice recommendation.
- Publish the Existing App:
-
Using the existing app, you could update the App Permissions and update any necessary workflow recipients if you changed to users/groups participating in the testing and then publish. You may want to delete any test documents created during verification.
Note: Be aware that newer documents would not start at 0001 since it will generate the next number after the last test document created.Although this method is viable, it is recommended to copy the app prior to publishing to have a fresh start.
Where to Test - Kuali Environments
Typically most testing can be done in your Production (PRD) environment - and we recommend you build/modify/verify your apps within this environment using Draft Mode and the above mentioned methods to test your app. Draft Mode enables an app creator to create a draft of a new version, test the form using the form preview, test the workflow in the workflow simulator and once validated publish those changes.
We do provide test environments for each institution that can be utilized if desired:
- Production (PRD):
-
Live environment where all users live. Although Kuali provides 3 environments, best practices have shown that creating, testing, and deploying in the Production environment offers the greatest efficiency.
- Sandbox (SBX):
-
Set your permissions in this environment to allow individual users to play and workout ideas without going live. This can also be utilized for training sessions locally.
- Staging (STG):
-
Use this environment to stage a limited testing environment wherein only a few users are added to test an app. This can also be utilized for training session locally.
Comments
0 comments
Article is closed for comments.