Your app works locally but breaks after release. What should you fix?

Find the last release that worked

Start with the failed release, the last good version, and one clear example of the error. Include the page or action, the time it happened, and what the customer expected. Remove passwords and private records from anything you share.

We would compare changes to the code, environment settings, dependencies, and database. A successful build only tells you that a build step passed. It does not prove a customer can sign in, save a request, or pay.

Put the release steps in the repository

GitHub Actions supports deployment environments, workflow history, and concurrency controls. Bitbucket Pipelines tracks deployments against named environments and supports manual deployment steps. Either can provide a recorded path from checked code to a running app.

Our recommendation is to keep the tool the team already uses unless it cannot meet the requirements. Write down the runtime version, dependency installation, checks, build, and deployment steps. If a release still needs someone to copy a file by hand, make that work visible before automating it.

Sources: GitHub: Deploying with Actions · Atlassian: Set up and monitor deployments

Give testing its own data and permissions

A preview URL is a poor test boundary if it still writes to the live customer database. We recommend a separate test environment with made-up records, restricted access, and provider test accounts. Check where each connection points before running a trial.

GitHub environments can restrict access to environment secrets and apply deployment rules. Availability depends on the repository's visibility and GitHub plan, so check the rules your account actually supports. Agree who approves a live release and record that decision.

Sources: GitHub: Deployment environments and rules

Give the release job only the access it needs

A deployment job should not need a developer's personal administrator account. List what the job must change and restrict it to that work.

GitHub Actions can use OpenID Connect, or OIDC, to obtain short-lived cloud credentials through a configured trust relationship. That avoids storing a long-lived cloud key for that connection. The cloud-side rules still need to limit which repository, workflow context, and role may use it.

Sources: GitHub: OpenID Connect

Try the task a customer came to do

For an example appointment website, loading the home page is not enough. A test should choose a time, record the booking in the test system, and show a clear result. A repeated click should not create a second booking. This is an example acceptance check, not a client result.

We would also check a phone-sized screen, missing information, a failed connected service, and access from another test account. Choose checks based on what could hurt the business. Start with a few useful ones and add coverage when a failure exposes a gap.

Plan for a release that needs to be undone

Keep a known good app version and clear instructions for returning to it. Treat database changes separately: an older app may no longer understand a changed table. We recommend checking compatibility and testing recovery in an isolated environment before calling rollback ready.

Name the person watching the release and the signals that would make them stop it. Record when the backup was taken and what a restore would lose. A backup file alone is not evidence that the team can restore the service.

The first improvement may be small: one repeatable release, one test of the main customer task, and one recovery exercise. Agree on that result before expanding the work.