LCS - Before setting your application live

Steps the developer should make prior to changing an application live for the first time in Betty Blocks.

Inform the LCS Service Team

  1. Enter a support ticket via the Low Code Solutions interest form . Select Support for the application I am building. This will create a WiscIT ticket for the service team to track. 

Test the application in Sandbox (UAT/DEV) 

  1. Following the Testing section as outlined in LCS - Best Practices for the Software Development Lifecycle(SDLC) in Betty Blocks
  2. Provide the completed test plan and documentation to the support team (see Inform the LCS Service Team above).

Determine if SMTP was set-up and used correctly 

  1. Enter a support ticket to the LCS service team (see Inform the LCS Service Team above) if the SMTP credentials are not entered in the configurations.
  2. See LCS - Email set-up within an application for instructions on emailing from your Betty Blocks application

Determine if SSO is being used properly and data is secure

  1. Ensure you are not exposing data publicly that shouldn’t be exposed. See [Link for document 132459 is unavailable at this time] regarding public data vs. SSO-enabled data as well as the Terms of Service.
  2. Ensure your pages in Betty Blocks are secured properly per role(s)
  3. Ensure Manifest groups are set-up per the standards found in LCS - Configuration of Manifest groups for application role mapping
  4. Additional data security best practices:
    1. Use a GUID for page variable instead of the single digit ID
      1. The process is to add the GUID block from the store
      2. Have it generate on any create action for your main model
      3. Then place it in a property that you will use as the page variable and in filters
    2. Filter Data models to who needs the data
    3. Add validation on data models on at least one property to stop empty records
    4. Add validation on "Belongs to" relations

Prepare and document your application for Production

  1. Remove unused elements from your build. Recommended to do this in a sandbox first to see/fix possible errors.
  2. Rename all important data and buttons
  3. Provide descriptions in Data Models
  4. Provide descriptions in Actions
  5. Use Settings data model for static data models that want to move exact data to Prod that was loaded in your Sandbox environment for specific data models.
  6. Create documentation for other developers
  7. Create documentation for end/application users and per role if multiple roles are utilized in the application
  8. Determine which end/application users should be in which Manifest groups/roles.
  9. Determine how you want to roll the application out and how you want to communicate to the end/application users how to log-in and what they will see once they log-in.

Review your application for accessibility

  1. Review the Betty Blocks Accessibility and Usability Information KB to ensure you have an understanding of potential barriers to accessibility.
    1. Review the Digital accessibility @ UW-Madison webpage for additional information on the Digital Accessibility Policy
  2. Run an accessibility check on your application using the recommended WAVE Web Accessibility Evaluation Tool.

Configure Hostname, DNS and SSL certificate on the DNS

  1. See LCS - Add a custom hostname in Betty Blocks and LCS - Request and setup a SSL certificate for setting up instructions.
    1. Please note: Betty blocks requires a minimum of 14 days to complete the certificate initiation, so plan this into your schedule.
  2. If you configure these on your own, without the LCS service team's assistance, please take screenshots and send them to the LCS service team via the support ticket mentioned in the Inform the LCS Service Team section above.

Determine the application's criticality to the unit's mission 

  1. UW's Betty Blocks platform is stored in a private cloud, managed by Betty Blocks. Therefore, back-up is an obligation of Betty Blocks as well as up-time.
  2. In the unanticipated event that the application can't be reached, document how the application users will be made aware the situation and what downtime procedures/manual workaround processes they should follow until the application becomes available. 

Determine who is handling the application’s support 

  1. Per the Terms of Service, the Application Manager/Developer is responsible for supporting the users and data of the application. Determine how that support will happen and how communication between support and the application users will occur. 
  2. In the IT inventory, add the support email and person that LCS service team should direct someone to if the application user contacts the LCS team instead. 

Regression test in Production

  1. Before providing the URL to application users, perform a regression test on the primary user stories to ensure everything is working in Production as expected.

KeywordsProd, go-live, testing   Doc ID133629
OwnerJeanne H.GroupLow Code Solutions
Created2023-12-18 12:12:54Updated2024-06-12 13:54:52
SitesDoIT Enterprise Business Systems - Low Code Solutions
Feedback  0   0