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.
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.
This sandbox is for the client to check the application before going to production.
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.
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.
If you only decide to work in one sandbox, choose the one called Development.
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.
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.
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.
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.
Select a page in the options CUSTOM 404 PAGE, CUSTOM 500 PAGE (FATAL ERROR), and CUSTOM PAGE FOR MAINTENANCE MODE.
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.
There are three types of email communication configurations that can be used:
Demo settings (Flowmailer)
Send the emails from the host by default @betty.app.
Custom SMTP configuration
Send the emails via a whitelisted domain. The domain that has been provided in the domain field needs to be verified within your SMTP provider. Otherwise, the emails will not be delivered.
Make your application’s design reusable by converting it into a template. Use a template if you’re expecting similar applications.
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.
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.
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.