To get the best out of a development team most teams define strict communication guidelines and workflows. Those workflows usually are based, among other things, on git flow and include automations like whenever you're pushing a commit, your CI will perform some tests. Or a Slack bot automatically sends a new message to your dev channel when a Pull Request is labeled with e.g.
In other scenarios you want to bypass some defined workflows when a bot like Dependabot is automatically creating pull requests to keep the noise level low.
Following those workflows closely makes sure everyone on your team knows when to do what, when someone needs help or something needs to be reviewed.
By default the WunderPreview Bot creates a new comment in your pull request with a link to your preview. WunderPreview then builds and deploys your preview whenever you open a preview url like
https://1ym4crpwnqzc7ui2buf1a7dtky.wdpr.run for the first time. You'll need to wait a few minutes to let WunderPreview complete the build and deployment process until the actual preview is displayed.
With the WunderPreview Workflow settings, you can control when and how the WunderPreview bot engages. On top, you can even define if WunderPreview should automatically start to build and deploy a preview when the
Needs Review label is applied to a pull request.
This speeds up the overall preview process as in most scenarios, your preview is already live before you even had time to check your changes.
The Workflow settings enable you to:
Needs Reviewis applied to the pull request.
Let's assume that your teams process is to create pull requests very early on while the feature is still work in progress or even before you start working on it. Before a PR can be merged, at least one other developer and in some cases even a non-technical stakeholder needs to review your changes (on a visual basis). Your team also has a Slack bot that informs you about when certain PR labels are applied or removed. Last but not least, every PR by default gets the labels
Work in Progress
So everyone that is checking the pull requests immediately sees that it's a feature and someone is working on it.
Just take a glance at Automattics pull requests list for wp-calypso. Based on the labels alone, you instantly know what's going on: The "Plans grid" pull request is still in progress but the pull requests "Nav-Unification", "Deduplicate ..." and "Editing Toolkit" are already ready for review.
Back to your amazing feature. You keep working on it and as soon as you're done, you send out the preview link to your reviewers. As explained earlier, whenever a preview is opened for the first time, WunderPreview starts to build and deploy the app which can take a few minutes.
While most developers are used to randomly stare at loading spinners, waiting for the CI to turn green, the average non-tech-stakeholder isn't.
To reduce the time anyone needs to wait to a minimum, you're just removing the
Work in Progress label and apply the
Needs Review label. As soon as you've applied the label the Slack bot e.g. informs your team that your feature can be reviewed and WunderPreview automatically kicks in and starts to build and deploy your app.
So whenever the preview link is opened for the first time the preview is already up and running. ✨
There are scenarios when you don't want the WunderPreview Bot to post preview links to your pull requests. Scenarios like PRs that are opened by other bots like Dependabot or chore PRs that does not need to be previewed. In this case you can apply the same Needs Review-label filter as you'd use for the Auto Build feature.
Do you have any questions or remarks? Just send us an email to email@example.com. We are happy to hear from you!