Auto deployment is extremely useful when installations need to be carried out at multiple locations in a quick and effective manner.

One of our customers, one of the major ISVs in Behavioral health with over a hundred client installations, were handling many such installations manually.  The process in place used deployment via remote connection to all Prod Systems, consuming significant business days. The other challenge was that the client would decide on when to upgrade to the newer version which essentially means each instance may not necessary have the latest version and they may later decide to jump to a newer version (may not be the latest). This typically requires a highly customized deployment process which requires large amount of manual effort unless automated.

Nalashaa’s Proposed Solution

Nalashaa proposed a solution which was oriented towards a Client – Server Model, where Server acts like a Release Management System, and Client is a Deployment Agent in a Production Environment.

The solution we proposed consists of following components:

1. Build Manager
2. Release Manager
3. Deployment Agent
   1. App Deployer
   2. Schema Deployer
   3. Hotfix Handler
   4. Instance Monitor – DashBoard

Designed Process

• The Build Manager is responsible for creating build artifacts including Schema changes from different release lines in respective directories.
• These releases are maintained by Release Manager via configuration. Release Manager decides which build will be deployed on which particular Client Production Environment.
• The Deployment Agent consists of App Deployer that deploys the application files on the server, Schema Deployer that is responsible for database changes, and Hotfix Handler that manages the hotfix on a particular Production Environment. This Deployment Agent is triggered by a Scheduler, and is configurable to run on client specific time.
• The Instance Monitor produces a dashboard exhibiting the latest build/hotfix version deployed on each Production Environment along with the deployment status for every release.
• Additionally, Audit and Deployment log will be maintained on Build System and Production System respectively, and each activity is logged as it progresses.

How does Auto Deployment Work?

App Deployer is triggered by the Scheduler, which requests the build version from the Release Manager. The Release Manager returns with the build/hotfix version to be deployed on the Production System. If the version returned is the same as deployed one, no further action is required, and the process stops.

If the versions are different, database changes are carried out by Schema Deployer. Once database changes results in success then deployment of files is done in the server by App Deployer. In case of Hotfix, Hotfix Handler deploys the hotfix on the server. At any stage, if the deployment process fails, original state of the Prod System is restored. If the deployment is successful, the configuration on Production System is updated. At all times, activities are logged.

After each deployment, the logs from the Production System are transferred back to the Build Server, which are then used by Release Manager to produce a dashboard on the Build Machine showing the current status in each Production Environment.

By implementing the above architecture, the deployment was automated for the ISV, and brought about significant operational overhaul and efficiency improvements to the existing deployment model.