Bitbucket Server 4.8 is all about faster turnaround time for pull requests and zero downtime backup. Keep reading to learn about three new features and how each one helps teams collaborate to produce higher quality code.
Break down big or long-running pull requests with commit-level review
Pull requests make collaboration easier for developers wherever and whoever you are in the code review process. Plus, they help teams follow best code review practices by including specified reviewers in the workflow. But what if you're the reviewer and you would like to review individual commits added to a pull request quickly?
The new commit-level review provides per-commit diff views and commenting within pull requests to help reviewers do just that – review individual commits added to a pull request. For example, if a pull request author has thoughtfully broken down their work into logical commits, you can now step through the changes for each commit. And at any time the effective diff for the whole pull request is still available for the “big picture” view.
Commit-level review is also really handy when returning to a pull request that you’ve already reviewed. You can see how your feedback has been incorporated without having it mixed up with changes you’ve already seen, because commit-level review allows you to view and comment on individual changes, one at a time. Highlighting changes at this granular level makes the reviewing experience better for every member on the team and will result in faster pull request turnarounds.
Set up default reviewers for pull requests
The focus on commit-level review in Bitbucket Server 4.8 is no coincidence, because pull requests are at the heart of workflows in Bitbucket. Along with reviewing pull requests, adding a reviewer should be easy. But not all teams have a frictionless process for assigning reviewers.
For example, do you have a release gatekeeper on your team that reviews or merges every pull request? Or are you on a small team and everyone is asked to review each pull request? What if you’d like to avoid building up a list of reviewers from scratch for every pull request? With the new default reviewer feature, on any given repo you can configure a default set of reviewers that will be pre-populated on the pull request creation form. Default reviewers can even be defined by source and target branch, and once it’s set up you can add or remove people from the list as needed.
In addition, a new merge check is available for specifying that a certain number of these default reviewers must approve before a merge can occur. By setting up these checks, you can make sure the release manager gets a heads-up on pull requests targeting release branches, the senior dev approves all changes to the default branch, and the bug-master reviews all the bug fixes. This granularity of configuration by branch is a powerful tool and is one of the many ways that the pull request experience is unique to help your team be innovative.
Back up data without downtime
Backups are business as usual for any company that relies on hosted software. An important aspect of backups is making sure that consistent copies of data are made using supported mechanisms, and that has meant some amount of regular downtime. If you have builds that run at night and the downtime happens at night, then your builds will fail. If you have teams halfway around the world, then your nighttime is their daytime, resulting in downtime during their working hours.
In Bitbucket Server and Bitbucket Data Center 4.8, it’s now possible to create a backup without locking or shutting down the instance to reduce downtime due to backups. As long as your file system and database snapshots are each consistent within themselves (various vendor-supported options exist for each) a restore where the snapshots aren’t in sync with each other will now result in a working instance that’s tolerant to minor inconsistencies where operations occurred during the backup period.
In addition, Bitbucket Data Center has an active recovery mode that can be run on start-up to find, log, and resolve any inconsistencies between filesystem and database. The addition of zero downtime backup to active-active clustering in Bitbucket Data Center is another way to ensure constant access for users.
For more details on zero downtime backup, see our updated documentation.
All of the new features released in Bitbucket Server 4.8 provides teams with Git best practices and make collaboration easier for teams. Whether you’re the reviewer of a pull request or need to assign a reviewer, the two new pull request features make code reviews easier for quick turnaround times and better quality code. The same can be said for zero downtime backup: with an active recovery mode, work is not put on hold and collaboration doesn’t need to come to a halt whether you’re dependent on clients or team members in different timezones. It’s through these features that teams can make sure that team members stay close to (working) code to produce higher code quality.
Update to Bitbucket Server 4.8
Check out the release notes for more information on these new features and the other improvements we’ve made in 4.8.
Did you find this post useful? Share it on your social network of choice so others can produce higher code quality, too!
