My Betty Blocks is an application management environment that enables you to create new apps, invite or delete users, and work with sandboxes and other settings of your applications. This guide is going to walk you through the sets of development standards and best practices to take into account while managing your applications.
Sandboxes
Users with permission to Create applications are able to create a new application. After the production application is created, it’s recommended to create 3 sandboxes (aka DTAP). In order to do this, one needs permission to Create sandboxes (and branches).
Each sandbox has its own purpose. It’s possible to customize every sandbox with an icon and background image for the [sandbox].bettyblocks.com login page. Be careful: if you choose a high resolution, this will reflect on the loading time of this page.
Acceptance
This sandbox is for the client to check the application before going to production.
Use identifier:
[application name]-acceptance
Testing
All development is tested here. If there are issues, they have to be fixed in development. Next, they could be merged into this sandbox to test it again. It’s advised to use automated testing.
Use identifier:[application name]-testing
Development
The builder does his development work in this sandbox. Once he/she finished the work on a feature, it’s better to merge the changes into the Testing sandbox. This way (updated) features could be tested frequently.
Use identifier:[application name]-development
If you only decide to work in one sandbox, choose the one called Development.
Merges
A merge can be executed between two environments. Merging is only possible with the following permissions:
The permission Merge changes to the production application must be active when merging to the production environment.
The permission Merge changes within the sandbox manager must be active when merging between sandbox environments.
Be aware when merging one or more than one data model that has the settings Is settings model active will overwrite the parent’s settings.
Furthermore, the advice is to merge on a daily basis. We do not recommend merging changes into production on Fridays and on the weekend. In case of merge errors, the resources to fix them will be limited.
Status
An application has per default the application status Development. The application status has to be changed to Live when the app is used by the customer. The status change to Live is only possible for non-trial organizations and can only be changed by customers with an active license. Furthermore, the status can only be configured with the permission to Change application status (promote application to production). You can ask support for more information about the contract.
Types
Default applications
Default applications are applications that are developed by or on behalf of a customer using the platform.
Included:
All apps that are connected to your company/organization
Apps that have the status of live & development
Apps that are not used anymore
Excluded:
Application types playground & training
Best practices:
The admin should review the apps that aren’t used or not put to production to remove the periodically
In case of an event with lots of apps being built, please contact your Customer Succes Manager
Production applications
A production application is the highest application in the development, testing, acceptance, and production (DTAP) deployment street. It is very similar to a default application, with some exceptions that you can read below.
Included:
All application types: default, playground & training
All application statuses: development, live & disabled
Excluded:
Sandboxes & branches
Playground applications
A playground application is an application of the type of playground.
Included:
Apps that aren’t used anymore, but aren’t removed
Demo applications that are used internally, anonymously or externally
Apps that are used internally, anonymously or externally but don’t have the status live.
Excluded:
Application types default & training
Best practices:
The admin should review the apps that aren’t used or not put to production to remove them periodically
Read more about playground applications in this article.
Training applications
A training application is an application of the type of training.
Included:
Apps that aren’t used anymore, but aren’t removed
Demo applications that are used internally, anonymously, or externally
Apps that are used internally, anonymously, or externally but don’t have the status live.
Excluded:
Application types default & training
Best practices:
The admin should review the apps that aren’t used or not put into production to remove them periodically
Read more about training applications in this article.
Settings
Options
Below are several options described that should be configured before going live:
Upload an icon and background to see the difference per application in the application overview.
Turn off the option logging on production environments for better performance.
Web options
Below are several web options described that can be configured.
The option CROSS-ORIGIN RESOURCE SHARING PROTECTION must always be turned on.
The option ALLOW IN IFRAME has to be on the option Deny or Same origin.
CSP (Content Security Policy) can be used to make exceptions.
More options here.
Example: frame-ancestors 'self' https://*.bettyblocks.com/ https://*.bettywebblocks.com/; script-src https://*.bettyblocks.com/; style-src https://*.bettyblocks.com/; font-src https://*.bettyblocks.com/;
Select a page in the options CUSTOM 404 PAGE, CUSTOM 500 PAGE (FATAL ERROR), and CUSTOM PAGE FOR MAINTENANCE MODE.
Custom hostnames
Custom hostnames can be verified for a specific application and can be linked to a domain. It may take up some time, so take the following actions into account when using custom hostnames.
Verify the hostname. This can take a while due to DNS caching.
Process the SSL certificate into the platform. An SSL certificate is required before a redirect to the Betty application is possible. See more information here.
Templates
Make your application’s design reusable by converting it into a template. Use a template if you’re expecting similar applications.
Branches
Creating a branch will be an exact copy of the parent application.
Use branches when multiple developers work on different functionalities. Therefore, these functionalities can be brought to the next sandbox without having to merge the partially finished work of the other developer. Also, in case of emergency fixes, it’s wise to have a separate branch ready, next to your feature branches.
When working on the same functionality in different branches, be aware that the sandbox you’re merging into will be affected twice. Keep an open eye on the changes.
Another scenario can include some external party needing their own environment with the possibility of using their own data or disabling sensitive data for the other environments.
User management
The admin of an application needs to ensure that only active users have access to the application. If a builder is done with the development, the user type Builder can be changed to User, or the user can be removed from the application.
Roles & Permissions
Roles and permissions can make sure that the users in the organization stay organized. Creating new roles can be done by going to the user management of your organization or in an application. Extra roles besides the roles Admin and Member (like the roles Customer admin and/or Merger) could come in handy for larger teams. A role like a Merger could be set so these users are only allowed to merge changes into sandboxes.
Another important note: only Betty users can have the role of Admin.
Block store
The block store is the place to share custom components, data sources, functions, and themes within an organization. You have to maintain the shared blocks in the block store: keep them up to date or delete them when they aren’t functioning anymore.
Find out more about reusability via the block store in this section of articles.