Hot Deploying Components
The eiDashboard can make changes to routes and deploy new components to the eiPlatform without requiring a server restart. The eiPlatform can accept new components and/or updates to existing components via hot deploy. This page covers the ability to hot deploy to a running eiPlatform.
Go To Interface Settings
Importing routes, interfaces, and formats can be accomplished on this page. To import a component, perform the following steps:
1. Select an interface in the Interfaces panel. The interface selected on this panel is where the component will be imported to. The ‘ROOT’ interface can also be selected to import to the base Working Directory.
2. Click on the Actions button and select Import.
3. Upload an .eipb file that has been previously exported either from the eiConsole or from the eiDashboard.
The eiPlatform will first check for components that will be overwritten and display a warning message detailing which will be affected. The components are then immediately deployed to the eiPlatform and activated.
Hot Deploy Best Practices and Limitations
Since hot deploying involves applying changes to a running eiPlatform, often in a production environment, it is important to understand the best practices and limitations to reduce the chance for data and transaction loss. The following section highlights some of the recommended ways in which hot deploy should be used.
- Prior to hot deploying components, we highly recommend first staging any changes against a full copy of the eiPlatform’s Working Directory using the eiConsole. Testing thoroughly will reveal any potential conflicts or unforeseen errors that would be difficult to correct post-deployment.
- Only bundle those components that are meant to be imported. Although the eiPlatform will ignore any unchanged components in an import bundle, it is safest to limit the import to only the necessary items and Target hot deployments at the Interface level.
- Deploying new components to an eiPlatform is a very safe procedure, from a both a transaction and continuity standpoint. Since there are no existing components to swap, the chance for data loss is almost none.
- Updating existing components on a running eiPlatform is a more complicated process under-the-hood. Since routes must be stopped and swapped when updating there is an opportunity for transaction loss, though it is best mitigated by hot deploying upgrades during periods where throughput is expected to be low. The eiPlatform will store any queued Transactions during hot deployment and process them when deployment is done, but there is a small window during stopping and reactivating components in which transactions can be lost if the transaction volume is too high.