An application can be deployed to a zone, which is a combination of an environment and a region. This explains the rules governing the various environments. A list of all zones is also available.
| Name | Description | Expiry | Cluster sizes |
|---|---|---|---|
dev |
Used for manual development testing. | 7 days | 1 |
perf |
Used for manual performance testing. | 7 days | min(3, spec) |
test |
Used for automated system tests. | 2 hours | 1 |
staging |
Used for automated staging tests. | 6 hours | min(max(2, 0.1 * spec), spec) |
prod |
Hosts all production deployments. | No expiry | max(2, spec) |
Deployments in prod must have at least one more node than required to handle peak load.
A cluster is a container or content cluster,
and a regular application has a container and a content cluster.
A minimal, typical prod deployment therefore has 4 nodes.
dev and perf are deployed to directly as part of development or testing.
To make it convenient to deploy applications from prod to dev and perf without modification, resources are automatically downscaled in these zones. To control the resources you get in these zones, specify them explicitly for the environment in question (dev or perf) as described in deployment variants.
To deploy to the perf environment, use
mvn package vespa:deploy -Denvironment=perf
In dev and perf, the latest active Vespa version is used when deploying.
An instance is not upgraded, unless deployed to.
This means that sometimes, a deploy takes longer than normal,
as it invokes a Vespa upgrade before deploying the application package.