Legacy - Production deployment tips
When you develop customizations to applications on the ServiceNow® platform, you deploy them via the application repository to a production instance. This topic examines and provides cautions for the tradeoffs between installing an application from the application repository versus Git repository with source control.
Try building and editing apps in the current version of ServiceNow Studio instead. For more information, see ServiceNow Studio.
Overview or deploying to production
Technically, you can still “deploy” an application from a Git repository to a production instance using source control. This can have unintended consequences.
Glossary of terms
| Term | Definition |
|---|---|
| Metadata or application files | The sys_metadata records that define configuration in ServiceNow and are packaged in an application. These records alter the behavior of the instance but do not contain data such as incident or CMDB records. (See Note below) |
| Scoped applications | ServiceNow applications that restrict allowing only updates and operations within the boundary of the scope. This mechanism is used for most new development. |
| Global applications | Global applications are developed in the legacy global scope. Work is often done in this scope to customize existing ServiceNow applications such as IT Service Management (ITSM). |
| Application repository | Applications are typically published here for deployment in production instances. Although the application repository has separate entitlement rules, it operates similarly to the ServiceNow Store. |
| ServiceNow Store | Repository for third-party (vendor) applications as well as ServiceNow published applications. Most customers do not publish to the Store, but often install applications from it. |
| Update sets | Standard method of packaging customizations for deployment in each successive instance. They contain the incremental collection of insertions, updates, and deletions. |
| Legacy - Delta loading | The most efficient method of loading because it changes only from source control rather than earlier uninstall/reinstall methods. |
| Schema | Definition of tables and columns in the tables. |
| Rollback | Administrators can roll back the last installation of a selected application. A rollback removes all code, table, and file updates from the initial installation. |
Installation location
When you install source control, it facilitates the ongoing development of a custom application. Therefore, the application is managed as an “In development” application in the Custom Application [sys_app] table rather than as an “Installed” application in the Store Application [sys_store_app] table. Both tables are extensions of sys_scope so they both provide the same protections and restrictions as the scope. So when you search for the installation of a source control deployed application, refer to the System Application [sys_app] table and the in development section of the Application Manager page.You cannot have a sys_app record on the instance while deploying that same application from the ServiceNow Store or application repository. The two deployment models are mutually exclusive. If at any point the deployment model changes, the sys_app record must be converted to a sys_store_app record first. You can contact ServiceNow Support for help with performing that operation.
Delta loading
Prior to the ServiceNow Paris release, application installation from source control always removed and reinstalled the entire application when triggered, including the Apply Remote Changes function. With Legacy - Delta loading, now only the changes update, simplifying the process considerably.
| Application type | Install source | Schema present in package | Schema contains data | Claim by another app (Global) | Expected outcome for data and schema |
|---|---|---|---|---|---|
| Scoped | Application repository or Store | Yes | Yes/No | N/A | Preserved |
| Scoped | Application repository or Store | No | Yes/No | N/A | Preserved |
| Scoped | Source control | Yes | Yes/No | N/A | Preserved |
| Scoped | Source control | No | Yes/No | N/A | Removed |
| Global | Source control, Application repository, or Store | Yes | Yes/No | Yes/No | Preserved |
| No | Yes | No | Preserved (1) | ||
| No | No | Yes | Preserved (2) | ||
| Source control | No | No | No | Removed (3) | |
| Application repository | No | No | No | Preserved |
- While the database schema and the data are preserved, they will be moved into the default global application.
- While the database schema and the data are preserved, they will be moved into the global application which previously held claim to these files if installed. Otherwise, they will move into default global application.
- Applicable only on custom columns with u_ prefix. ServiceNow platform-authored columns are not dropped.
When switching branches in source control for a scoped application, use extreme caution in a production environment. If the target branch is missing schema elements found in the current branch, the related schema is dropped, destroying any data it contains. (Global applications do not drop schema when data is present.)
Just as with update sets, only a subset of the incremental changes needs to be applied with Delta loading. Unlike update sets, the application package represents the complete application. Files that are absent from the new package are deleted. This can alter functionality and delete data. Update sets and applications upgraded from the application repository or ServiceNow Store must have an explicit DELETE payload to remove a file or drop a schema.
Direct edits to the repository, especially to remove files, can have significant ramifications, including loss of data and cascading deletes. Perform this action with care.