Operations | Monitoring | ITSM | DevOps | Cloud

Tracking tests on non-default branches was one of the most requested capabilities during the Bitbucket Tests (beta). We heard you, and today, we’re shipping it. Most teams don’t ship from main. Integration happens on develop, stabilisation on staging, releases cut from release. Until now, Bitbucket Tests only tracked the tests from default(main) branch, leaving the branches that actually matter invisible. Multiple branch tracking in Tests changes that.

We launched Bitbucket Packages to give teams one place to manage code, pipelines, and artifacts, and we’ve been expanding it ever since, first with Maven and npm, then PyPI and NuGet. Every one of those packages has shared one trait: it lives inside a single repository and inherits that repository’s permissions. Most of the time, that’s exactly what you want. But it also means sharing a package across repositories has meant granting people access to source code they never needed to see.

You shouldn’t have to grant full repository admin rights just to let an engineer or release manager trigger a deployment. To solve the all-or-nothing access problem, Bitbucket Pipelines introduces custom deployment permissions (Beta). You can now gate specific environments to authorized users and groups, ensuring safer releases and easier compliance. Left: Add users and groups to gate deployments for this environment.

In January we launched Tests in Bitbucket Pipelines – a single place to track, organize, and understand your test health over time. In April we added automatic flaky test detection so unreliable tests get flagged before they slow your team down. But spotting a problem is only half the battle. Day to day, your team still needs to act on a test – track it as work, clean it up, or route it to the right person.