A production publish is performed to an instance of the Agentry Production Server typically when it is time to deploy the application to users. Additionally, production environments are normally established for the purposes of quality assurance testing prior to deployment. This can include publishing a new application project or publishing modifications to an existing project to create a new application version.
A production publish will transfer the application project from the Agentry Editor to the Agentry Production Server. The location of the project on the file system for the Server is the Server’s installation location in the sub-directory Application\Production. The entire project is written to a single file at this location with an extension of .agp. This file encapsulates the application for the version published, which is specified in the publish wizard.
During the production publish the version number and deployment date and time can be specified. The specified version number can affect the behavior of the application during client-server synchronization of the new version, with a change to the major version number having one effect and a change to the minor or modification number another.
As a part of the process of performing a production publish, the version number for the application must be specified. The first time a production publish is performed to the Agentry Production Server, the version umber will be 1.0. During subsequent production publishes to the same Server instance, the version number is changed based on the selection made in the Publish Wizard.
An Agentry project’s publish version contains three components, a major, minor, and modification number. In the publish version 3.2 mod 1, the 3 is the major version, 2 is the minor version, and 1 is the modification number. The Publish Wizard will contain a section where the developer will specify which of these should be changed. This selection impacts the behavior of the application during the next synchronization by the Agentry Clients.
The specific difference is related to the processing of transactions sent from the Client to the Server. Depending on the nature of the change made to the application, it is possible that changes captured on the Client in transactions using the previous application version will be incompatible with the new version of those same transactions. When the synchronization definitions of the transaction (server data state or update steps) perform processing that will not work with the previous version of the application, it is necessary to process those transactions with the previous application version. To force this behavior change the production publish version by incrementing the major version number.
When a new major version is specified, the Agentry Production Server will process each transaction sent by a Client using the old version of the application. Once all transactions have been processed, the new version of the application will be sent to the Client and dictate any subsequent synchronization behaviors. When either the minor or modification numbers are changed, the new version of the application takes effect immediately, before the pending transactions on the client are processed.
Because of this behavior, it is the responsibility of the developer performing the publish to determine which behavior is desired, and to then select the proper change to the publish version of the application.
As of Agentry version 5.1 it is possible to create a cluster of Agentry Production Servers when those Server instances are deployed for the same application and serving the same user group. When the Server instances are clustered they communicate with one another to verify consistency in the deployment among all Server instances. A major component to this consistency is verification that each instance within the cluster contains the same published version of the application.
When performing a production publish to a server instance within a cluster it is important to understand the behavior of the Server and how it handles the new application version. Each Server instance within a cluster will defer loading application definitions for a new production publish until all members of that cluster contain the same version. Until this criteria is met, the previous version of the application will continue to be treated as the latest version. Once all cluster members have received the same version of the application, they will then all load this new version, at which time it will then be deployed to Clients.
The Agentry Editor will allow a publish to be performed to an instance of the Agentry Production Server that is a cluster member. It is possible to then perform multiple publish operations, once to each member of the cluster.
AppName-vX-Y-Z-app.agp
AppName-vX-Y-Z-app.ini
AppName matches the Name attribute of the application definition within the project. X, Y, and Z are the major, minor, and modification numbers of the publish version, respectively. These files should be copied to the Application\Production directory for each Agentry Production Server instance within the cluster. The Server instances will recognize the presence of these files and load them when all Server’s have received the same version.
This method of copying the files manually is recommended over publishing so as to reduce the chance of error related to specification of the publish version. During multiple publish operations, if the publish version is specified differently for any one publish to the cluster, the new published version will never be loaded by the cluster members. Copying the files manually insures that the publish version is the same for all cluster members. This can also be automated with the use of a batch script that can copy the files from the source Server to the members of the cluster.
In many environments, the production or run time environment is not readily accessible to the developer who performs the production publish. Alternately, it may be the standard practice and policy to take the final validated and approved application directly from the test environment and implement it in the production environment.