A snapshot of a mabl branch - master or any other branch - is a collection of test versions that exist in a workspace when the snapshot is created. While development branches enable you to make isolated changes to tests, snapshots freeze the state of your tests and flows at a certain point in time and pin them to a mabl environment.
This article explains how snapshots work.
Managing snapshots
For instructions on how to set up a snapshot environment, see the article on managing snapshots.
Use case
The main use case for snapshots is to run a set of tests against a stable environment, where no further changes in the application are expected. Meanwhile, in other environments that are being actively updated, you can continue to develop tests and flows. As code changes are promoted across environments in the CI/CD pipeline, test changes can be promoted alongside by triggering a new snapshot.
If you want to give snapshots a try, we recommend against using a snapshot for the first environment within your deployment pipeline and instead snapshotting downstream environments.
In this setup, your master branch in mabl runs against your first environment, and you can update your master without worrying about updating snapshot versions or affecting downstream environments. When the code gets deployed to a downstream environment, you can update the respective snapshot off of master.
Consider branches
If you need to actively develop and run multiple versions of the same test in parallel, such as two different versions of a checkout test, branches are a better fit than snapshots. Snapshots are designed to freeze a moment-in-time state of your tests, not to maintain side-by-side active versions.
How it works
Snapshots are created by triggering a deployment event with the --snapshot-from option. This command pins the environment to the latest version of tests on a mabl branch.
When a snapshot is created for an environment, mabl runs the specific version of tests and flows that the snapshot was created from. Plan runs in that environment use the snapshot version by default, whether they are triggered on schedule, manually, or via the API.
Runs on a snapshot environment are indicated with a branch icon
As tests and flows are updated, plan runs in the snapshot environment still use the snapshot version until the snapshot is updated or removed. For more detailed instructions on creating, updating, and removing snapshots, check out the article on managing snapshots.
Snapshots are only supported for plan runs in the mabl cloud, which includes plans triggered on a schedule, manually from the plan details page, or via the deployments API. Ad hoc test runs use the latest version on the selected branch, regardless of which environment they run in. Tests triggered via mabl tests run --from-plan-id execute locally and do not inherit the snapshot.
Sample scenario
To illustrate how snapshots work, consider the following deployment pipeline, where snapshots are pinned to two downstream environments: QA and Prod.
When a developer makes changes to the user registration flow in their app on a code branch called “user_registration_update”, they update the affected end-to-end tests in mabl and save the changes to a mabl branch of the same name: “user_registration_update”.
After running and validating the branched version of mabl tests in the local app environment, the code is merged to master and deployed to a Dev environment. The mabl branch is also merged to master, and the updated master test version runs against the Dev environment right after deployment and on a schedule, once a night.
At this moment, the code changes haven’t been deployed to the two downstream environments: QA and Prod. These environments are running a snapshotted version of the tests that is older than the updated master.
When the code gets deployed from Dev to QA, the snapshot for the QA environment gets updated with the latest master version of the tests while Prod continues to run its older snapshot version.
Snippets are not snapshotted
Reusable snippets do not adhere to snapshots. Updating a snippet affects all environments, including snapshotted ones. To pin a snippet to a snapshot, save it as a one-time snippet inside a reusable flow.
Learn more
To get started with creating snapshots, check out our documentation on managing snapshots.