• Application Development Best Practices
  • Planning and Design
  • Development Phase
    • Using Sandboxes
    • Branches
  • Development philosophies
  • Testing
  • Adding testers to the application
  • Implementing the Lifecycle

Application Development Best Practices

The Software Development Life Cycle (SDLC) is a process that produces software with the highest quality and lowest cost in the shortest time possible. While following these general phases of the lifecycle:

• Requirement analysis
• Planning
• Software design such as architectural design
• Software development
• Testing
• Deployment

This Document will delve into the planning, design, development, and testing aspects of SDLC with a focus on how to achieve that inside our low code solution.

Planning and Design

Planning your application for development in Betty Blocks requires many of the same strategies that any development process should take. This stage is where writing or drawing out and understanding what the application should accomplish and who will be accomplishing those actions is key to being successful in this stage. The outcome of this stage could include a list of User Stories; data flow diagrams; list of requirements to name a few options.

The Design phase encompasses taking the documentation you created in the planning phase and turning that into both visual designs and technical documentation around how the application will be built.

Development Phase

When developing an application, the success and maintainability of the application can many times be tied back to the setup and usage of smart development practices. One of those practices is developing in dedicated environments. On the Betty Blocks platform, the separation of environments is provided by sandboxes and branches. We strongly recommend every non-playground application to have at least two sandboxes.

Using Sandboxes

To create a sandbox in an application, go to the my.bettyblocks.com page for the application. There are two sections “Production Application” and “Sandbox Manager”.

In the sandbox manager section click on the “Create new sandbox” this will create an exact copy of your application.

Required Sandboxes for Production applications

• Top Level Sandbox
  • Name: User Acceptance Testing or UAT
  • Identifier: uat
  • This sandbox will be the Main testing sandbox for the application.
• Second-level Sandbox
  • Name: Development or DEV
  • Identifier: dev
  • This sandbox is to be the primary development environment.

If you decide to make more sandboxes, the service team would be interested in your use case.

Some Keys about Sandboxes:

• Changes can ONLY be made in the lowest Sandbox.
• Configurations are specific to the sandbox.
• SSO must be configured for any Sandbox individually, once configured the sandbox cannot be deleted or the SSO will need reconfigured.
• Merging changes from a sandbox up to the next sandbox or production level is all or nothing. The option to pick which changes to merge is not possible.
• Previewing changes made in an upper-level Sandbox can be done via the direct URL.

Branches

Branches are a new feature. It is recommended to only make one branch at a time and use them for minor changes and merging them and then deleting them once the changes are completed. Having multiple branches can cause conflicts and cause the loss of changes in one branch. Use Branches with caution for now. The service team will not configure SSO or SMTP for branches.

Development philosophies

There are two main development methodologies; Waterfall and Agile. In the Waterfall style of developing, you complete the entire application or update in one long development cycle and deliver many features all at once. The second Method is Agile which is focused on developing and delivering in an iterative and higher frequency than waterfall. The development cycles in Agile are called sprints and usually consist of a one or two week block of time.

It is recommended to adopt an Agile or Agile-like methodology. In Betty Blocks this would mean breaking up the development into sprints and merging the completed tasks from a single sprint up to the UAT sandbox. The changes from the last sprint can then be validated in the following sprint in UAT. Once testing is completed and approved, all changes can be merged from UAT to production.

This development pattern decreases the likelihood that a change will negatively impact the production application and will bring bugs to the surface faster. As changes are merged into production the application’s documentation and test plans need updated to reflect any new changes.

Testing

Building a consistent and structured testing process can help developers build high quality applications and limit the rework that needs to be completed to fix bugs.

Some keys to the Testing phase are:

• Create a test plan
  • Define how to test each feature and consistently test the feature every time to catch regressions.
  • Log test runs and the outcome of the tests so that feedback can be used in subsequent development cycles.
• Tests should be concrete with defined outcomes. It is often helpful to start with the user stories that you developed the application with as your base line tests.
• Employ multiple testers, not everyone will use an application the way it was designed. Having a variety of test users can expose usability or functionality issues with the application.
• It is also advisable to use “negative path” or “non-happy path” testing to ensure that features are tested for when the application is used in a purposefully incorrect manner.

Essentials Test Plan example

Adding testers to the application

There will be times that testers are not developers of the application, but they need access to test the applications. By default, Betty Blocks denies access to sandboxes and applications in development from the public with a feature called Private Data Mode (PDM). For non-developers to access the application in the UAT sandbox an application admin can temporarily deactivate PDM. Contact the Service Team to guide you through this process.

• LCS - Adding users to an application that don’t have NetIDs

Implementing the Lifecycle

Following SDLC best practices does not have to be an all or nothing approach. It is often helpful to assess where in the process you or your team are and then incrementally drive toward including additional practices as you or the team are ready for them. This incremental process with help drives better adoption and allows for continual improvement as the key to building a successful SDLC is to ensure the process works for the team/individual.