Discover the key points to approach the application testing and deployment processes before going live.
After reading this article you’ll know the following:
-
What the DTAP-street term means
-
DTAP environments and their purposes
-
Workflow and best practices for DTAP-street
When developing a Betty Blocks application, builders normally keep various versions of their applications in separate environments. These environments come as an arrangement of versions of the same application created and processed for different purposes. This arrangement is called DTAP-street. In this article, we’ll break down this term and explain what each environment is used for.
What is a DTAP-street?
The DTAP-street term stands for Development, Testing, Acceptance, and Production and it’s a common method of phasing software development and deployment. It provides a structured framework for organizing your development process ensuring that applications are built, tested, and deployed systematically.
Each of the phases of DTAP is carried out in a separate environment. Within Betty Blocks, these environments are called sandboxes - copies of your application in which you can make changes without taking them into your live application.
Let’s break down each environment and define its purpose.
Development
The development environment is the starting point for any project on the Betty Blocks platform. Here, developers create and shape the application. It is a controlled sandbox where experimentation and testing can occur without impacting live data. This environment provides a safe space for developers to innovate and implement changes.
Testing
Once the development work is done, the application is moved to the testing environment. This stage ensures that the application functions as intended. Quality Assurance (QA) specialists test the application's functionality, including actions, workflows, and features. Any issues are identified and resolved before progressing to the next stage.
Acceptance
In the acceptance environment, the application is tested with either dummy or real data, depending on project requirements. This is where clients or stakeholders evaluate the application to ensure it aligns with their specific requirements. It serves as a bridge between development and production, enabling thorough validation.
Production
The production environment is the live environment where the application is accessible to end-users. It represents the final stage in the DTAP street. Here, the application is operational, and users can interact with it. It's essential to ensure that the application is stable, secure, and performs optimally in this live environment.
Workflow and best practices
While the topic of DTAP-street can be extended as much as possible, we won’t go into too much detail in this article. Instead, we’ll just give you some valuable pieces of advice on what you need to take into account while working on this topic.
Sandboxes
As mentioned before, using sandboxes is a key feature for the DTAP-street flow. You need sandboxes to be able to make mistakes without losing valuable information and progress. They are your backup: if you merge or break something in the production environment while not having a sandbox - you won’t be able to recover your work.
To learn more about sandboxes, we recommend looking into the Creating a sandbox article.
Version control and continuous integration
Version control is essential for managing changes within the DTAP street. When changes are merged, a snapshot of the application is created and pushed to the next environment. This snapshot serves as a safety net, allowing developers to roll back changes once within a sandbox if issues arise.
Continuous integration is a process that streamlines the flow of changes between environments, making development more efficient. It enables quick iteration and switching between sandboxes, providing developers with the ability to revert changes when necessary. However, it's important to remember that each sandbox allows only one rollback.
Best practices
-
Access to all environments. Developers should have access to all environments, at least the main developers. Different environments may have distinct data and configurations, and this access is essential for diagnosing and resolving issues that may vary from one environment to another.
-
Data variability. While some data should remain consistent across environments, not all data needs to be identical. Care should be taken when sharing data to ensure it is relevant to the specific environment.
-
Caution with settings models. Settings models should contain data that remains consistent across all environments. For instance, a ‘Status’ model can be shared because it is consistent throughout the development cycle.
-
Timely merging. Merging should only occur when everything is completed, or when it's ensured that no half-functional features can be publicly accessed in other environments. Betty Blocks does not work with versions, making careful merging a critical practice.
-
External testing and SSO configuration. For external testing with stakeholders who don't have Betty Blocks accounts, disable the public data model (PDM) or enable testing status for that specific sandbox. When using single sign-on (SSO), enable it only in the production environment or in development for testing purposes, considering that not all users may have SSO accounts.
By following these DTAP-street best practices, Betty Blocks platform developers can set up a structured, efficient, and (mostly) error-free software development process. And remember: a well-chosen approach contributes to the creation of applications that are thoroughly tested, client-approved, and ready for a successful launch in the live environment!