Zuora Testing and Deployment Best Practices
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.
Testing and Deployment Best Practice
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.
- Development sandbox(es).
- Merging environment (Integrating environment where the code from all the development environments are synced).
- User Acceptance Testing (UAT) sandbox.
- 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.
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.
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.
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.
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.
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.
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.
Deployment Considerations with Zuora 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.
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.
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.
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.