Pushing and syncing changes

As described in the Overview, the configuration of your data model, business rules, scripts, views, permissions, etc., is collectively referred to as the metadata of your app.

To make changes to the metadata, you must use the app builder, which is accessible only in the development and staging environments. The production environment does not allow direct changes; instead, you need to synchronize changes (see below). However, you can adjust environment settings from the app monitor to customize behavior (more on environment settings below).

Next, we will outline the process for implementing changes to your apps and synchronizing those changes to the production environment.

Making changes to your app #

You can modify your app’s metadata through the app builder. Here, you can view your app’s definition and implement necessary changes. Note that these changes won’t take effect immediately; they need to be pushed to the app runtime, where they will be applied. For instance, if you add a new field using the app builder, you won’t see it in the app immediately after saving. First, you need to push the changes, and once this is done, the new field will appear in the app runtime of the development environment.

You can push changes from the app builder using the Push changes action in the secondary menu (a shortcut is also available with Ctrl + P). When changes are pushed, you’ll see a summary of the changes that will be pushed, and you’ll have the option to create a backup and provide an explanation for the changes.

Enabling the backup flag creates a version that can be restored later. Typically, you wouldn’t create a backup with every push; rather, you’d do so when you need a restore point.

Importantly, understand the impact of pushing changes:

1. The app will be halted in the development environment (production remains unaffected).
2. Metadata changes are transferred to the app runtime.
3. If metadata changes affect data, necessary data adjustments are made. For instance, if a field is deleted, all records of that entity will be updated to remove the field.
4. Changes to legacy services are deployed, removed, or redeployed.
5. The app is restarted.

Synchronizing changes #

Once you’ve tested all changes in the development environment, if you have a staging or production environment in your app, you can sync these changes from development to production.

From the app builder, use the Sync changes to <target env> action in the secondary menu to synchronize changes. During this process, you’ll see a summary of the changes that will be moved to production. It’s important to note that only changes that have been pushed will be synced. Any changes made in the app builder but not yet pushed won’t be synchronized.

When syncing changes, the following steps occur:

1. App metadata is exported from the development environment.
2. The production environment is halted.
3. App metadata is imported into the production environment.
4. Data refactorings are carried out.
5. Legacy services are synchronized.
6. The production app is restarted.

Depending on the nature of changes and any required data refactorings, this process might take some time. Ensure you understand the implications of potential data refactorings (see Automatic Refactorings) and sync changes at a time that minimally impacts operations.

Additionally, keep in mind that if your app is linked to others, changes will also be synced across linked apps, following the same process described above.

Automated Issue Resolution #

Before initiating the sync process, the application metadata undergoes validation. If validation uncovers errors, a tool to automatically resolve these issues will be available.

Incorporating a staging environment #

A staging environment can be added as an intermediary between development and production. Some use cases include:

• Hotfixes: Your staging environment can mirror your production version. In the event of a production issue, you can fix it in staging and then sync the fix to production, avoiding unintended changes from development.
• QA: After completing a development iteration, instead of syncing directly to production, you can sync to staging, perform regression testing, and then sync to production once testing is complete.

When a staging environment is present, changes made in development are synced to staging first, and then you can proceed to sync them to production.

Environment settings #

You may have noticed that there is no app builder available in the production environment. This is because making direct changes in the production environment is discouraged. Changes should be made in the development or staging environment, tested, and then synced to production.

However, your production environment might require slightly different behavior than your development or staging environments. This could involve using a different API key, an alternative alerts policy, or even a distinct theme for easy differentiation between production and development.

This is where environment settings come into play. These settings can be customized per environment and, combined with metadata, influence how your app operates.

You can modify environment settings from the app builder in the development or staging environment. For the production environment, these settings can be adjusted using the app monitor.

For more information on different environment settings, refer to the following documentation:

• Environment Variables
• UI Settings
• Logs and Alerts
• Localization