Blogs

Zuora Testing and Deployment Best Practices

By Prachi Bhatia posted 05-10-2022 15:07

  

Financial processes implemented on Zuora are highly complex and specific for every single company.   Zuora offers a variety of configurable features to allow our customers to implement their unique version. This complexity requires attentive and deep implementation in a development environment and detailed testing from both IT and business teams (UAT).

As IT teams embrace agile processes to enhance the speed of change and go to market, deployment automation is being built to support this.

It will ultimately lead to successful changes without human error, as well as multiple deployments within a week or even a day.

This article aims to provide a set of best practices to assist you in your change management journey.


1. Testing and Deployment Best Practice

1.1 Define a Testing Strategy

Develop a solid testing approach and determine which environments will be required to execute the strategy.

A good practice is to have at least three or more stages in the deployment process.

  1. Development sandbox(es).
  2. Merging environment (Integrating environment where the code from all the dev environments are synced).
  3. UAT sandbox.
  4. Production environment.

In this way, you can thoroughly test the changes to the configuration and the financial processes supported by the applications. The bad practice would be to test your changes in production, which unfortunately happens more often than you would expect. As a result, users will have no control over errors and failures, which will directly impact the front end.

Usually, the trend is to deploy the last successful set of configurations tested in the UAT environment. Regardless of the approach, don't skip testing. 

Deployment Manager Best Practices

1.2 Automate testing

Automate tests to cover the large majority of your use cases.  Automated Test Scripts programmatically perform validations. 

Another good practice is to run automated testing as much as possible. Automation of test scripts is time-effective, accurate, and improves the bottom line of the business operations. As a result, bugs are uncovered more quickly and fixed more efficiently.


1.3 Business test using relevant data

In the case of major releases and changes directly impacting the business, your business users should test those changes in a production environment.

Another good practice is to run the UAT in a production-like environment.  This will help the business users understand the change and certify that it works as expected.


1.4 Test the performance at peak 

If you have large data or expect spikes in volumes, dedicate some time to perform testing in a production-like environment. Performance Testing of the production-like environment will assist in monitoring the latency issues and stability of the tenant.


1.5 Keep your master data aligned with production

Testing is most effective when the testing environment is clean. It is essential to clean and maintain production-like environments before each deployment. If environments are kept running for a long time keeping track of all the configuration changes and updates that cause failures and errors can be difficult.

Avoid modifying the product-like environment before any deployment.


1.6 Establish Appropriate Permission Levels

It is best to have well-defined roles with the required set of permissions for the users who can actually deploy from one environment to another. They should have the proper credentials and permissions before deploying from one environment to another. 


1.7 Continuous Deployments and Releases

Continuous Deployment involves automating the release of a good build to the production environment. This makes the change management process more agile as the releases are managed in short iterations continuously. 


2. Deployment Considerations with Zuora Deployment Manager and Central Sandbox

2.1 Deployment Manager

Zuora recently launched a feature called Zuora Deployment Manager® that provides full capabilities of comparison, validation, deployment, and roll-back, in order to support the best practices for deployment and testing.


Creating Deployment

The user experience for creating new deployments is intuitive and captures the Multi-entity. It may be in the best interest of the users to provide a description of Development: UAT or Production: UAT etc


Validating Deployment

The compare screen will check the potential sources of errors without making changes. It guides the users for the parameters with differences, no change, parameters that are in target only, parameters that cannot be reverted, and any feature which requires T9 permissions activation. Please refer to the known facts and limitations of Deployment Manager here.


Observability of Deployment

Observability is one of the most essential aspects of deployment. Zuora Deployment Manager captures the success and failure of API calls in logs so that users can understand what is happening in the backend, away from the user interface.

It is vital to maintain a record of the history of changes; currently, Deployment Manager allows users to download the information of the deployments in a CSV format. Maintaining an audit trail can be made easier this way.


2.2 New to Deployment Manager

If you are new to Deployment Manager, take a walkthrough of the feature on the following URL on Knowledge Base Zuora Deployment Manager or find A reference in the Community Post Zuora Deployment Manager Demo

2.3 Central Sandbox

 

Zuora Central Sandbox is a centralised environment to test all Zuora features, including new pricing scenarios, customer acquisition channels, payment gateway connections, data migration efforts and new functionality, with real production data and settings. 

 

Self-Service

The newly launched self-service refresh feature gives greater control of customer’s testing cycles by allowing production to central sandbox refreshes without the need to contact support.

 

API Testing

This sandbox positions customers to perform adequate testing for large-scale change initiatives where bulk updates need to be made via API in order to test and confirm that the changes are configured correctly.

 

Data Load Testing

In addition to API Testing, Central Sandbox also allows customers to perform adequate testing for large-scale change initiatives such as chart of accounts updates, bulk price increase changes, bulk contact updates, bulk billing account updates.

 

Bill Runs and Payment Runs:

Central Sandbox enables customers to perform adequate testing for billing-related questions related to large-scale change initiatives such as product-line swaps/changes 

For more information, please refer Zuora_Central_Sandbox

 

Overall, Central Sandbox significantly improves testing cycle time by providing a test environment that behaves and provides functionality that is consistent with the production environment.

0 comments
90 views