Review Apps: See Feature Live

What are Review Apps?

A review app is a temporary, fully functional environment that is automatically deployed during development, for example, when creating a merge request (also called a pull request). It is based on the respective development branch and receives its own independent infrastructure components, including:

• A dedicated database instance
• Message queues
• Its own storage space

Additionally, there are supporting services, such as a development mail server, since emails should not actually be sent from review apps.

The entire process of the application review—the assessment of the new application version—is significantly simplified as a result. Features can be tested realistically without affecting other developers or test environments.

How are Review Apps Used?

A review app can support the entire development workflow, from the development of a new feature to its release for production.

Tests by Developers

 Since the review app runs independently of other instances, tests can be performed on it in addition to the local development environment. Problems that arise, such as a corrupt database, can be easily corrected because review apps and their dedicated infrastructure components can simply be deleted and redeployed. Long-term tests, which would otherwise require additional effort, are also easy to implement.

Feedback 

Feedback processes are made much simpler. Thanks to the availability of the review app, feedback from project management, design, or other developers can be gathered easily and, most importantly, asynchronously.

Automated Tests 

We run a wide range of automated tests. This is a central part of a Continuous Integration strategy. These tests include static code checks, unit and integration tests, various security and vulnerability tests, as well as regression tests that can detect unintended UI changes early on, during active development. Automated testing ensures code quality with every single change.

Review 

The review of new features and improvements by testers, developers, project management, design, etc., can be carried out directly on the review instances. This means they are not first tested on dedicated test instances. This significantly reduces the development and feedback time for adjustments and consequently helps to improve quality.

Client 

For some features, it makes sense to involve the client early in the development process to test or clarify features. This can significantly shorten development cycles, especially when integrating third-party systems.

Availability 

A review app is not only available for development branches but is also provided for the main development branches up to pre-production. Thanks to Continuous Deployment, they are fully automatically updated with every change, which is similar to classic, dedicated test instances but far more dynamic. This means up-to-date instances are always available for testing, checking, or simply looking something up.

Monitoring 

Of course, review apps can also be subjected to comprehensive monitoring. This allows for the early detection of background errors, performance issues, stability problems, or hardware resource bottlenecks.

What is Needed for Review Apps?

Supporting an application review is anything but a trivial process. A major challenge lies in the dynamic nature of configurations. Instead of providing a handful of configurations for test and production environments, the application's configuration and its dependencies must be fully dynamic. If a new application is being developed from scratch on a »green field«, the use of review apps can be incorporated into architectural decisions from the very beginning. However, existing applications can also be migrated, which involves similar considerations.

1. Dependencies 

Applications often have dependencies on other services such as databases, email servers, payment providers, or other external APIs. For each of these dependencies, a decision must be made on how to handle them in test environments. In environments like review apps, it is undesirable for emails to be sent to external users or for payments to be processed. To prevent this, the dependencies in the review app must be configured to, for example, use a dedicated test API, send emails to a development mail server, or simply do nothing at all.

2. Deployment 

A central part is the automated deployment of the review apps. This requires detailed consideration of how the application itself is deployed and how it and its dependencies are configured.

3. Application 

How is a package for the application created and configured? How can it be accessed? Web applications and other services can, for example, be started as containers on a Docker or Kubernetes server, with access controlled via a wildcard domain (e.g., <branch>.ops.example.com). This can create further dependencies. For existing applications, for instance, the capability to run them in a container must first be established. This creates additional requirements for the infrastructure, such as enabling access via dynamic domain names.

4. External Dependencies 

If the application has external dependencies, such as a database, consideration must also be given to how these can be dynamically provided for each application. For databases, it is a good idea to create a separate database for each review application from a backup. Other services can be started in parallel with the application as containers or configured once as a central development service. Other dependencies, like message queues or storage, can be managed using naming conventions and paths. Files, for example, can be stored in the storage under review/<branch>/ and cleaned up later. Ultimately, the handling of each individual dependency must be analyzed and defined.

5. Build Environment 

For the entire process of building and deploying the application to happen automatically, a build server is required. Such systems are the foundation of Continuous Integration and Continuous Deployment. If a system is already established in the company, it can be used. If not, services like GitLab, GitHub, Azure DevOps, or Jenkins are good options. However, a tool should be chosen that the company is willing to commit to long-term, as it requires building up corresponding expertise.

Security and Configuration Management 

The automated jobs responsible for deploying the applications must also provide the review apps with the necessary variables for their configuration. It must be ensured that sensitive data such as passwords, API keys, deployment keys, certificates, etc., are protected from unauthorized access, including from internal developers. This can be achieved through measures on the build server or by using external secret servers like Azure Key Vault or AWS Secrets Manager.

Test Data 

In many applications, simply deploying the services in their basic configuration makes little sense. Usable test data is needed. Considerations must be made about where this data comes from and how it is made available to developers and for the deployment of the review apps. Depending on the project, this could be full or partial snapshots of production data, updated once or regularly, an anonymized set of test data, or manually entered data, perhaps supplemented by generated values. This can vary greatly from project to project. What is crucial, however, is that the test data is of sufficient quality so that the application can be operated and tested meaningfully, without having to worry about encountering errors with »real data« in production.

Lifecycle Management 

Most review apps do not run for long. As soon as a development is merged into the main development branch and the merge request is closed, the review app is stopped. It is important that no data debris is left behind, as it would accumulate quickly. Therefore, it must be ensured that stopping the review app deletes not only the service itself but also all its created dependencies, such as databases, message queues, directories in storage, etc. This can happen either directly when the instance is stopped or, for example, in nightly cleanup jobs. Furthermore, it can be useful for some quasi-static review apps to be supplied with fresh test data, for instance, through a job that restores a current database snapshot on selected test instances every night.

Monitoring 

Centralized monitoring, logging, and tracing of applications and infrastructure are useful not just for review apps, but in general. It is a significant gain for the application's quality and for the time it takes to find and fix problems when issues are actively and automatically reported, and logs, metrics, and traces can be queried centrally. Services that can collect and accumulate these logs and metrics from various sources, such as Grafana or AWS CloudWatch, are well-suited for this.

How Fusonic Deploys Review Apps

For us, review apps are not an exception but the living standard. Our deep know-how and years of optimized frameworks allow us to get from a code change to a runnable review app in often just a matter of minutes.

For you as a client, this means:

• Faster feedback: Test changes immediately in a real environment.
• Higher quality: Identify bugs before they reach production.
• More transparency: See the current state of development at any time.

This efficiency, which has proven itself even in highly secure environments like the banking sector, is the foundation for a successful partnership. With Fusonic, you choose a development partner who understands review apps as a core part of an agile process, leading your projects to their goal faster and more securely.