Appshare Testing Best Practice

To benefit the most from a local node and at the same time being efficient with testing new applications on the Appshare platform, it is usually best to follow these guidelines.

Use your Appshare Local Node against your JDEdwards production environment to support production transactions. Obviously you can also access all other JDEDwards environments from that same node should that be required.

When new applications are made available to you, or new features have been added to existing ones, the developers will include a beta testing link in your application to access the new features for testing purposes. This testing will most likely be done in non prod environnments and occur on a pre-production Appshare node, indicated in the picture above as staging node at the bottom of the picture.

When tested successfully, the new application or application feature will be deployed in the Appshare cloud. The beta testing link in the application will disappear, as the new application of feature is now available in the common Appshare platform.

The local administrator can now apply the new Appshare image to the local node, to make the feature available in the Appshare local node.

Appshare Change Management

The above picture depicts the standard change management cycle we use for Appshare. A change to an application is made in an isolated codeline, called a branch. Once completed, this code is deployed and published to the user that can access this code using the ‘Beta Testing’  link in the application. Once the change is tested and accepted, it is then deployed to the standard Appshare code.

When you use a local node to run Appshare, this local node needs to be updated to the latest image by your local administrator.