> For the complete documentation index, see [llms.txt](https://knowledgebase.fabricdata.com/fabric-knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledgebase.fabricdata.com/fabric-knowledge-base/support/releases/client-qa-testing-and-release-approval.md). # Client QA Testing & Release Approval The formal process for **Fabric** **testing** and deploying system and software patches, service packs, and hot fixes involve several critical steps. Additional testing is also carried out on client QA environments by both Fabric and **Client testing** teams to ensure Live/Production releases are as seamless as possible. The goal of this process is to ensure that updates are thoroughly tested and deployed to production environments efficiently with minimal impact on business operations. ## Critical Steps: ### **1. Define the Scope:** The first step is to define the scope of the patches, service packs, hot fixes, etc. that need to be deployed and tested. This will include a list of system changes, application updates, migrations, any features to be toggled off/on, environment variables to be altered and any downtime or maintenance windows required. Any new tests to be added to Fabric’s automated testing suite should also be identified here. ### **2. Test Plan:** Once the scope is defined, a detailed **internal** test plan is outlined with the steps required to test the updates. This will include a list of test cases, test data, and expected results. ### **3. Test Execution:** The **internal** test plan is executed, making sure to thoroughly test each update in a controlled environment. Any issues or defects that are identified are documented. ### **4. Defect Resolution:** Once issues are identified, they are prioritised based on severity and the actions required to resolve them are outlined. This could include additional testing, code changes, or communication with the customer. ### **5. Deployment Plan:** A detailed deployment plan which outlines ALL steps to deploy the updates to each individual production systems. This should include a list of system changes, application updates, migrations, any features to be toggled off/on, environment variables to be altered and any downtime or maintenance windows required. ### **6. Deployment Testing:** Following the deployment plan, the test plan outlined with the list of test cases, test data, and expected results per environment will be run again on the client QA environment. Any issues or defects are identified, documented and communicated to clients. ### **7. Post-Deployment Verification:** Verify that the updates were successfully deployed and that all systems and applications are functioning as expected. Document any issues or defects that are identified. **Clients will have 2 weeks following a QA release to test their environment and raise any concerns or issues with the deployment.** If the concerns/issues cannot be resolved then a client may opt out of the Month’s Live release. ### **8. Reporting and Communication:** Fabric will provide regular reports to relevant stakeholders on the status of deployment & testing efforts. This should include progress updates, issue resolution status, and any impact on business operations. ### **9. Continuous Improvement:** Fabric strives to continuously evaluate and improve the testing and deployment process to ensure it remains effective and efficient. This includes incorporating feedback from stakeholders, identifying areas for process improvement, and updating documentation and procedures as needed. ## Environment pre/post release testing and deployment Fabric's approach to environment releases and deployments aim to minimise disruption to users and maintain maximum availability for client production environments. Fabric's deployment process typically does not cause any downtime during production releases. In situations where a change has the potential to cause disruption to users, Fabric proactively communicates with clients to arrange a suitable release window before deploying to production environments. To ensure seamless and efficient deployment, Fabric adheres to **Bitbucket's best practices for deployments**. This approach helps to ensure that code changes are thoroughly tested and validated before being deployed to production, reducing the risk of errors or bugs that may result in downtime or performance issues for clients. * **Test Deployments:** QA deployments are thoroughly before releasing code changes to Live/Production environments. This includes functional testing, performance testing, and regression testing. Clients will also have 2 weeks following their QA environment release to flag any issues or concerns they would have with promoting their QA environment → Live/Production environment. * **Monitor Deployments:** Fabric Monitors deployments and production environments to detect and address issues quickly. Bitbucket Pipelines are designed with alerts and notifications for failed deployments, errors, and performance issues. * **Rollbacks:** Fabric has detailed rollback plans in place in the case of a failed deployment or unexpected issues. We use Bitbucket Pipelines to automate rollback procedures and ensure that backups are in place. Fabric has a monthly release cadence for production environments to ensure the scope of the changes are always manageable. All releases including times and dates will be communicated with clients via email, the [website](https://www.fabricdata.com/release-notes), and with the clients customers project or customer success managers. {% hint style="info" %} Customers can implement a code freeze if they wish to ensure their environment has no changes during a particular time period. {% endhint %} ***
Related Articles * [Testing Criteria & QA Plan for New Feature Releases](/fabric-knowledge-base/support/releases/testing-criteria-and-qa-plan-for-new-feature-releases.md) * [Security](/fabric-knowledge-base/support/security.md) * [Infrastructure](/fabric-knowledge-base/support/infrastructure.md)