> For the complete documentation index, see [llms.txt](https://upsolver.gitbook.io/content/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://upsolver.gitbook.io/content/support-1/faqs/infrastructure.md).

# Infrastructure

Read the following FAQs to learn about the testing and deployment of new Upsolver versions and dry-run clusters.

### What is the testing and deployment process for new Upsolver versions? 

The continuous release cycle at Upsolver consists of constant improvements, up to twice a week, to the data ingestion mechanism and other infrastructure elements. Below is the process prior to the deployment of each software version to customers' clusters.

<table><thead><tr><th>Stage</th><th width="129">Environment</th><th width="266">Details</th><th>Requirement</th></tr></thead><tbody><tr><td>Feature-specific tests</td><td>Dev / QA</td><td>Based on the requirement of each feature or bug fix, tests are done to validate its performance and stability</td><td>All tests are completed successfully</td></tr><tr><td>Automated QA sanity tests</td><td>QA</td><td>Common platform usage scenarios are run to ensure no functionality has been affected by the code changes</td><td>All tests are completed successfully</td></tr><tr><td>Manual QA interface tests</td><td>QA</td><td>Main elements of the user interface are tested to ensure usability has not been affected by the code changes</td><td>All tests are completed successfully</td></tr><tr><td>2 Internal dry runs</td><td>Staging</td><td>The dry run mechanism runs both the existing and new versions on a small sample data set for each cluster, to verify data is handled correctly</td><td>Data processed and written by both versions is consistent and without differences</td></tr><tr><td>Customer clusters dry run</td><td>Production</td><td>The dry run mechanism runs both the existing and new versions on a small sample data set for each cluster, to verify data is handled correctly</td><td>Data processed and written by both versions is consistent and without differences</td></tr></tbody></table>

### What is a dry-run cluster?&#x20;

As part of testing a new version of Upsolver before deploying it to customers, dry-run clusters are created for a limited time to test the changes in safe, replicated environments.&#x20;

Dry-run clusters mimic the setup and configuration of a production system, enabling our developers to safely check the new version on a replicated environment and discover any differences.&#x20;

Occasionally, customers may notice instances in their accounts with a dry run suffix. These are used by Upsolver to improve the quality of our next release.&#x20;

**Details and schedule**&#x20;

Usually, dry-run clusters will run for **120 minutes**, on **Sunday** and **Wednesday** afternoons, replicating all the clusters in an organization. However, in some cases, dry-run clusters run outside of these timeframes, and for shorter/longer times, depending on the testing requirements.&#x20;

**How does this affect you?**&#x20;

Customer data is not affected in any way, nor is the customer billed in the form of Upsolver credits for these instances. Customers are only billed for the uptime of the clusters as part of EC2 payment. Furthermore, dry-run clusters are created with only one EC2 instance, so they can mimic production tasks without raising high costs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://upsolver.gitbook.io/content/support-1/faqs/infrastructure.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.