Additional admin best practices

This sections outlines best practices for lab maintenance operations, monitoring, upgrades and packaging services.

Mobile lab inspection

Due to the nature of the setup, you must periodically perform a physical inspection of the mobile lab. The purpose of the inspection is to review the current setup, and to check for damage that may impact the system.

The following should be inspected:

Check that all devices are connected to Wi-Fi
Check each physical device for a swollen battery (When lithium-ion batteries are overheated, over-charged, or simply reach an old age, the inner cells of the battery may emit a flammable electrolyte mixture, causing the battery to swell.)
Check that all devices are charging and that the battery level is 100%.
Check that device brightness is set to minimum.
Check that the devices are not locked.

Database maintenance

PostgreSQL, like any database software, requires certain tasks to be performed regularly to achieve optimum performance.

The following procedures are the most common:

Creation of backup copies of the data on a regular schedule
Periodic "vacuuming" of the database

For more information on database maintenance, see the PostgreSQL documentation

Logs and TMP cleanup

Even though the Digital Lab logs remove older data, some conditions cause certain log files to grow significantly. For example, the application packager log, Digital Lab audit.log, and database audit log.

You need to monitor the size of these logs and periodically perform cleanups.

Monitoring

Like any other production system, Digital Lab deployment requires monitoring for performance and availability.

The following types of monitoring are necessary:

Hardware	Memory CPU disk space Network consumption
Services	process/service availability
Network availability	URL monitoring
Devices	Device availability
Connectors	Connector availability
Database performance	PostgreSQL: https://bucardo.org/check_postgres/
Log files	Monitoring log files for exceptions and errors

Digital Lab provides various methods for effective monitoring:

REST API reference for Digital Lab: Any action related to Digital Lab can be executed via REST API. REST API calls can be used in a script for monitoring purposes.

Embedded statistics reporting engine. The Digital Lab Server aggregates statistics from the connector and exposes them via Prometheus reporter.

Digital Lab Log files are stored in the /log folder.

Upgrade process

Because of the system’s vital business value, the upgrade process must be rolled out in an organized and robust way.

Be sure to follow these best practices:

Never upgrade in place. Use two environments – your current system and another, new installation running in parallel. Follow the procedure in Migrate the Digital Lab server .
Backup. Backup regularly, not only before an upgrade. Digital Lab does not store transactional data in the database, but it is still good practice to keep your data safe.
Compatibility check. Allow end users to rerun their tests and actions with a new system, to assure compatibility of their assets with the new version, before going live.
Leverage tools provided by the vendor. Do not try to modify the system manually. Use a migration tool for mobile applications, for example.
Plan the migration and execution. Plan your actions before, during, and after the upgrade.

For full details, see the Best practices for upgrades.

Packaging services

Digital Lab works with both packaged and non-packaged mobile apps. Packaging is an instrumentation method that injects the Digital Lab intercept library into the application bundle and re-signs the app with proper credentials. The advantage of using packaged apps is to provide better object recognition for record/replay as well as additional sensors simulations (such as photo or fingerprint).

After you upload an app to Digital Lab, the server automatically attempts to package the app. This gives users the option of selecting either a packaged app or the original version when running a test. To enable the functionality of automatic app packaging and signing by Digital Lab, the administrator needs to set up the packaging and signing services.

The packaging service is also used during the upgrade process when the current app is upgraded with the latest version of the instrumentation library.

For general information about packaging services, including the manual procedure for packaging the apps, see App packaging and signing services.

Android packaging

By default, the Android packaging service is installed together with Digital Lab Server. It does not require any special configuration, but it can impact the overall performance of the Digital Lab Server machine because the packaging service is a Java process that runs on the server.

iOS packaging

The packaging procedure for iOS apps is slightly different.

iOS applications and agents can be signed/packaged using the embedded packaging service or a remote packaging service. The remote packaging service is required for installations with more than 100 mobile iOS devices, or if there is a need to use more than one developer account for different iOS devices. For further information, see iOS signing service