Prepare Your App for PR Testing
Pie Loop can only test what it can reach. A preview that never deploys the backend change will stop a run cold. So will a test account that cannot sign in, a flag that keeps the feature hidden, or a WAF that answers Pie with a challenge.
It comes down to five blockers. Clear them before your pilot starts and Pie opens the preview, signs in, lands on the changed feature, and runs the same critical path three times with nobody rescuing the run.
The Five Blockers
Name each item in your blocker inventory with one of these so everyone on the pilot means the same thing.
| Blocker | What Stopped Pie | Where to Fix It | Primary Owner |
|---|---|---|---|
| Preview blocker | The preview has the wrong service versions or missing dependencies | Build a Complete Preview Environment | Platform engineering |
| Access blocker | Pie cannot sign in or use the required role | Prepare Identity, Access, and Test Data | Application engineering |
| Data blocker | The target state or record is missing | Prepare Identity, Access, and Test Data | Application engineering |
| Flag blocker | The test account cannot see the changed feature | Make the Changed Feature Visible | Application engineering |
| Edge blocker | A WAF, rate limiter, bot rule, or CAPTCHA rejected Pie | Allow Pie Traffic Safely, then Configure Your Edge Platform | Security or platform engineering |
| Pie-side failure | The feature is reachable, but Pie infrastructure or the agent fails | Track the failure with your Pie contact | Pie engineering |
A run that never reached the feature is not a product failure. Record it as the blocker it was, fix the blocker, and rerun the same path.
How the Work Is Shared
Pie helps you identify and verify blockers, and ownership of each fix is agreed during pilot planning. Your application, platform, and security owners provide access, approve the changes, and keep the resulting configuration maintainable.
Do the enablement work before the measured pilot begins. The pilot should evaluate Pie’s testing, not whether an engineer can manually rescue each run.
What Pie Provides During Pilot Setup
Pie provides the egress addresses your environment needs to allow and verifies them with you during pilot setup. The applicable addresses depend on the execution path, because browser and mobile runs can egress differently, so never copy a range from another environment or an older document. Allow Pie Traffic Safely covers how to confirm the observed source IP from one real request in the rejecting component’s logs.
Decide which credentials you will store in Credential Manager. For web apps, capture the preview URL pattern your CI produces for each pull request.
What a Ready Pilot Looks Like
A pull request is ready when Pie can:
- Open one stable preview URL tied to the PR commit.
- Sign in with a dedicated test identity.
- Reach the changed feature with the required role and feature flags.
- Use deterministic test data that can be reset.
- Call every frontend and backend dependency needed by the feature.
- Run repeatedly without a WAF, bot check, CAPTCHA, or rate limit blocking it.
The acceptance test is simple. Run the same critical path three times from Pie. All three runs must reach the feature without manual intervention.
Collect this evidence before you enable PR runs:
- Preview URL and commit SHA
- One deployment manifest covering every changed service
- Health checks for the frontend and required services
- Test account, role, and enabled feature flags
- Seed and reset commands for test data
- The egress addresses Pie provided and the exact network-rule scope
- One blocked request timestamp and request ID, when edge access failed
- Three successful reachability runs
- Named owner for preview failures and access failures
Start with the preview environment, because every other blocker assumes Pie can already load the build.
Need Help?
- Support: support@pie.inc