Deployment Events
Summary
Summary
Learning targets 🧠
In this video, you will see how to:
- Outline deployment events in mabl
- Trigger or schedule deployment events
- Integrate these into your CI/CD pipeline
Review our documentation: Deployment Events
What are they?
A deployment event is an action that triggers plan runs by application and/or environment. It can be further refined by the use of a plan label. This action can kick off multiple plan runs in one action, or it can be used to limit a plan to run on just one of its environments.
For this lesson, we will show how to trigger a deployment event via the mabl UI via the New -> Deployment button on the home page.
Why are they important?
Deployment events are useful for triggering several plan runs in one action.
- Plan labels: You can get the most out of deployment events by leveraging plan labels to define specific test suites, such as regression, targeted regression, smoke, or a certain functionality or feature area. 💪
- Example: instead of putting your entire regression suite into one plan, you can divide it into several smaller plans, united by the same plan label (e.g. regression), and trigger a run of all plans with this label through a deployment event.
Getting started
Choose a plan
Deployment events happen on the plan level. Find an existing plan in your workspace that you'd like to run, and check that (1) the plan is active and (2) has a deployment trigger.
A plan is active when this toggle is on. (You will also need to ensure that at least one test in the plan is toggled on.)
To make sure the plan has a deployment trigger, click on the edit pencil and scroll down to the Triggers section to check that the "Run on deployment" trigger is present.
Add a plan label
- In the plan edit page, add a plan label to use for this demo, such as "deployment-event-demo."
- Click "Save plan." (This label can always be removed later on.)
Note: Plan labels allow you to run a defined set of plans. This is important because, depending on the arguments that you provide, deployment events are capable of triggering a lot of plan runs. For instance, if you mistakenly trigger a deployment event for a commonly used environment and forget to add other parameters, all active plans in this environment will run, and all those test runs will count towards your monthly quote of allocated runs. 😱
By adding a special label to our demo plan, we can ensure that it'll only trigger one plan run. 🙌
Trigger the deployment event
Note the application, environment, and plan label of the demo plan. You will use this information to kick off your deployment event.
- Go to the Home page and click on New -> Deployment
- Select the appropriate application, environment, and plan label from the dropdowns.
- Once you provide an application or environment, the page will present additional settings for overriding the base URL, browser, and credentials
- Click "Trigger deploy" and watch the results come in.😎
Review results
You'll be redirected to a results page for the deployment event. It will show live results for the plan(s) triggered by this event.
You can also review the results from deployment events in the Results section of the app.The "By Deployment" section gives a detailed overview of results for tests triggered by API
Taking it a step further
Developers spend a lot of their time working in the command line, and if you prefer that over a UI, you’re in luck! You can use the mabl CLI to create and kick off deployment events, without opening the mabl Desktop Application
Using the mabl CLI
The mabl CLI is a powerful command-line tool that encompasses many use cases beyond running tests on deployment. You can discover all the other ways to use the CLI here!
Using the CLI to trigger a deployment event that will run tests for a specified application on a specified environment is as easy as running this command:
mabl deployments create --application-id <application_id> --environment-id <environment_id>
Adding Plan labels to your command to be more targeted with your deployment events is also possible using the CLI. Simply include the -–labels flag, and mabl will only run the Plan(s)s with those label(s).
Environment, application and Plan IDs
These IDs can be found in your Workspace, but since we’re using the CLI, let’s find them using these commands that will return a list of these entities:
mabl applications list
mabl environments list
mabl plans list
If you have more than 10 applications, environments or Plans, add the --limit flag and the number you’d like mabl to return
You may notice a pattern that all environment IDs end in -e, all application IDs end in -a and all Plan IDs end in -p.
Why is this important?
If you work a lot in the command line, using the mabl CLI eliminates disruption from your normal workflow. Not only that, but you can also easily coordinate these test executions in the CLI with GitHub (if you use GitHub Checks for PRs and commits, GitHub Action Workflows or GitHub Issues). Mabl has integrations with other CI/CD tools, as well as flexible APIs to run end-to-end tests on deployment, no matter what you use for your CI/CD pipeline
CI/CD integrations
Continuously testing after a deployment or build gives peace of mind to everyone involved in the testing process - from developers and QE’s to product managers and leadership - because it greatly reduces the risk of defects making it into production.
For more information on setting up CI/CD, our native integrations and our API-based CI/CD integration, please check out the links below!