By Amber Frauenholtz on February 23, 2017
When you hear the terms security and speed, Git repository management may not be the first thing that comes to mind. But for software development teams, these 2 things translate into 1 big thing: productivity. Today we’re releasing Bitbucket Server 4.14 which includes access keys in branch permissions, automatic dashboard updates, and an email notification enhancement.
Keep reading to learn how these features can help your team move faster.
Access keys in branch permissions
Permissions and Git can be a tricky thing; without a tool to enforce access control, anyone can read or write to your repositories. In Bitbucket Server you can give users access to anything – a specific project, a single repository, or just a branch. You can also give permissions to access keys, which allow continuous integration servers and other automated processes to interact with your source code.
Previously, access keys were granted only at the project and repository level, causing some trouble when branch permissions were also applied. The only way around this was to create a user account for your CI server and explicitly grant it branch access like other members of your team.
In Bitbucket Server 4.14, access keys are now applicable at the branch level, thus avoiding extra user creation. Updating repository metadata on restricted branches is as easy selecting an access key in the branch permission’s dialog.
Automatic updates and email reviewer status
Next up, 2 new features that make getting information just a little bit faster. First an update to the personal dashboard – no more refreshing required. When changes are made to your pull requests, i.e. approval or comment, they’ll be reflected automatically on the dashboard. Waiting for your pull requests to be reviewed? Pop open a tab, sit back, relax, and watch the approvals roll in.
Second, an enhancement to pull request email notifications. Pull requests are imperative for ensuring high quality code, which is why we’ve built Bitbucket Server’s pull request experience to cater to teams.
Currently when updates to pull requests occur (i.e. a reviewer changes the status to ‘needs work‘), the subsequent email notification batches this change with many others. To get a good idea of all the activity, you’ll need to open the email and scroll through the updates.
In Bitbucket Server 4.14 you can now get a feel for changes by looking at the reviewer status in the notification header. A new ‘needs work‘ status is a quick indicator that the pull request needs revisiting.
Try Bitbucket Server
For more information on other improvements and bug fixes in Bitbucket Server & Data Center 4.14 check out our release notes.
By Claire Maynard on February 15, 2017
Since Bitbucket Pipelines launched back in October 2016, we’ve heard a tremendous amount of positive feedback and excitement about the new built-in CI/CD . A ton of you about how you’ve configured your Pipelines for use cases. For instance, we were thrilled with James Fairhurst’s blog about getting set up on Bitbucket Pipelines and Laravel and Ozren Lapcevic’s blog on building, testing and deploying Django App with Bitbucket Pipelines. We appreciate your commitment to sharing best practices with the rest of the community – thank you! Keep ’em coming!
Today we’re excited to share some of our own tutorials, including five new Pipelines language guides and four new deployment , making it even easier for you to set up Pipelines.
New Language Guides
New Deployment Guides
We’ve also added several deployment guides if you’re interested in fulfilling the full software development life-cycle with Bitbucket.
We’ll be adding more soon, so make sure to check back! As always, if you have feedback on any of these guides, please tweet us @Bitbucket Pipelines.
Haven’t tried Bitbucket Pipelines yet? Give it try!
Try Bitbucket Pipelines
By Tim Pettersen on February 1, 2017
At this very moment, members of Atlassian’s Bitbucket and SourceTree teams are converging on the city of Brussels, Belgium for the annual Git Merge conference and Git Contributors’ Summit. If you happen to be attending the conference, or are otherwise in the neighborhood, come along to our Beers on Bitbucket meetup on Thursday night to meet some of the developers behind Atlassian’s DVCS tools. In addition to providing (and imbibing) beer, we’ll be hosting a few short tech talks covering various aspects of our Git tools:
Bitbucket Architect Erik van Zijst will discuss our recent proposal to add clonebundle support to Git
- SourceTree Developer Mike Corsaro will give a tech talk on SourceTree’s combined usage of both native git and libgit2
- Bitbucket Developer Tim Pettersen (that’s me) will demo Bitbucket’s new built-in CI/CD service: Bitbucket Pipelines
Registration is free, so sign up here and come along to The Pentalounge, Pentahotel Brussels City Centre on Thursday from 5 – 7.30 to get your Git on.
Sadly the actual Git Merge conference is now sold out, but if you’re coming along keep an eye out for these cheerful Atlassians and bug them for some Bitbucket swag:
Also, make sure you catch my session Git aliases of the Gods! at 3.15pm for a fun and moderately educational look at how to use (and abuse) Git’s aliasing system. Actually it’s a single track conference, so you don’t have a choice ?
But more importantly, we’re excited to rub shoulders with both contributors and enthusiasts of the world’s most popular distributed version control system, and geek out on Git for 48 hours in Belgium.
By Abhin Chhabra on January 31, 2017
Imagine you’re working on a feature. You create a pull request with your changes and get some feedback. You update your pull request by adding another commit that addresses the feedback. Maybe you notice a typo. So you create another commit that fixes the typo. Very soon, your feature branch has a lot going on with all these commits:
So you get your PR approvals and you merge. But looking through your repository’s history, you notice that it looks busy. A lot of these commits don’t actually add any value to your repo’s history. They clutter up the blame, make bisects take longer and generally make the history hard to navigate.
Squash your commits in Bitbucket Cloud
You could always squash commits via the command line using “git merge –squash” but this is just another time consuming step, and it would be a lot easier to have it done for you from Bitbucket. Today we’re launching the ability for Git users to squash commits in feature branches when merging pull requests. Combining these commits will provide a clean, easy-to-follow history for your repo. This new merge strategy can be found when a pull request:
Merge commit (–no-ff) will keep all of your commits from your feature branch, while Squash (–squash) is the new option that will allow you to combine your commits and clean up your repo.
on squashing commits in Mercurial
This feature rollout applies only to Git and not Mercurial… yet. Squash requires exchange of obsolescence markers – part of the evolve extension – so we’re working with Mercurial’s maintainers to get evolve bundled in core Mercurial, as well as adding support for it in Bitbucket. For developers already using the evolve extension, we hope to have a beta for squashing in Mercurial available soon.
In order to help make features like this accessible to the community in the future, including through further development of the Mercurial platform, Bitbucket is making a charitable donation to the Software Freedom Conservancy. We’re proud to support the Software Freedom Conservancy and promote the development of platforms like Mercurial, and encourage you to keep a look out for advancements to come.
Next time you want to merge a pull request, try out the squash merge option and tell us what you think on Twitter.
If you’re new to Bitbucket, sign up for an account, import some code, add your team mates and have them review your code via a pull request. When you are ready to merge their feedback, you will find the new squash merge strategy.
Looking for more in depth information on this new feature? More information on squash merges can be found here.
Get started, it’s free
Have more specific questions about this post? Reach out to us on Twitter to get the information you need. Looking for squash merges in Bitbucket Server? Merge strategies are available in Bitbucket Server 4.9.
By Amber Frauenholtz on January 26, 2017
You’ve probably heard the word “simplify” floating around a lot this time of year. People are setting New Year’s resolutions, cutting the clutter, and generally, trying to do more with greater efficiency and focus. On the Bitbucket team, we’re trying to simplify too, which is why our first release of 2017 includes several new features to make your day to day a little easier.
Edit files in-browser
Fixing typos, editing README files, and making other small changes can require a fairly large amount of steps relative to the size of the change. First, you must clone the repository locally, then make your change, next push back up to Bitbucket, and finally create a pull request (if needed). Before you know it, a quick spelling change has taken 5 or 10 minutes. And for those who aren’t as prepared to make changes locally, for example a doc writer who hasn’t installed Git, this can be quite daunting.
In Bitbucket Server and Data Center 4.13, we’ve simplified the process by letting you edit files inside of Bitbucket. To help make your change, the editor pre-selects a syntax based on filetype, lets you add a commit message, and even offers the option to create a pull request on push. With no need to do anything locally, simple changes can be applied much more quickly.
Easily find related JIRA Software issues
The past few years we’ve made huge enhancements to our JIRA Software and Bitbucket integration. Features like smart commits, embedded issue information, and the development panel in JIRA improve visibility and save time. As part of our continued focus on this integration, today we’re releasing a small but powerful improvement to JIRA issue integration. Throughout the Bitbucket UI JIRA issue keys have been modified to become hyperlinks to JIRA, making it easier to locate and dig into related issues. Keys are now clickable in commit messages, pull request titles, and in branch names.
Built-in SAML 2.0 support in Bitbucket Data Center
For admins looking to simplify user management in Bitbucket Data Center, SAML 2.0 single sign-on support is now available out of the box. SAML support integrates into your existing infrastructure, providing developers a more secure and hassle free way to log in. Having only one username/password to maintain means quicker access to tools and less password reset requests for admins.
We support a large list of popular identity management providers including Okta, OneLogin, Azure, Active Directory (ADFS), Bitium and PingOne.
Upgrade to Bitbucket Server 4.13
No matter what your New Year’s resolution is, we can all use a bit more simplification in our lives. Small improvements lead to big gains. In this case, less time switching between tools, looking for links, or fighting with passwords means more time spent on whatever is important to you.
Upgrade to Bitbucket Server 4.13
But wait, that’s not all! In Bitbucket Server 4.13 we identified areas to use less memory by caching template rendering. With this improvement, 4.13 uses less memory than any other 4.X version of Bitbucket. For a list of other improvements and bug fixes check out our 4.13 release notes.
By Amber Van Hecke on January 20, 2017
Git tags have become essential to a Git workflow to mark specific points in your Git history (like referencing a specific version of a project by tagging a commit for your release). They reduce complexity, clean up your branch workflow, and are a way to mark exact versions of commits. If you change versions a lot, they are a life saver instead of just using branches, which commonly leaves you with lots of rarely used branches.
Add tags from the UI vs the command line
Bitbucket users have asked us how they can cut out this back and forth and tag commits directly from Bitbucket Cloud’s UI, and today we’re launching this capability to add git tags and regular mercurial tags directly to commits from the UI. The name of the tag, date/time, and author can be applied to any commit.
If you’re reading this thinking “why would someone tag a commit from the UI? The command line works just fine for me.” Lets look at where you can save time and find commits that need tagging in Bitbucket without switching over to the command line:
- Branches page: Quickly check that all features scheduled for release have been merged into your main branch, before creating your tag.
- Commit’s build status: Double-check the build status of your commit. If there’s a failing build, you might want to push some fixes before creating your tag!
Add tags from Bitbucket’s UI
To add a tag, navigate to a commit in your repository and click on the commit in need of a tag. In the details pane, on the right side of the commit view, you can see ‘current tags’ and ‘create tag’. Once ‘create tag’ is selected, the author and timestamp will automatically be recorded.
In the future we will be expanding tagging from the UI with the ability to add custom messages to compliment any annotated git tag applied in the UI. If you are looking for lightweight tags, they can still be added via our API but are not currently available in the UI.
Try tagging commits
If you already use Bitbucket, start saving time with this new feature and start tagging (allthethings). If you’re new to Bitbucket, sign up for a Bitbucket Cloud account, create a repo and make a commit to take it for a spin. If you get stuck, more in depth tagging documentation is available here.
Get started, it’s free
Have more specific questions about this post? Reach out to us on Twitter to get the information you need
By Raj Sarkar on January 6, 2017
[This guest post is written by Jesse Gibbs, Head of Product at Rollbar. Jesse is a developer turned product manager who has spent 15+ years at companies building tools for software development, devops, and QA teams.]
Rollbar notifies developers in real-time when critical errors occur in their production apps. And now, Rollbar integrates with Git repositories and issue tracking in Bitbucket so that developers can troubleshoot and fix errors fast, ensuring that important errors don’t slip through the cracks.
Let’s take a look at how this works:
Deep links to source code in stack traces
Every Rollbar error report includes a full stack trace. With Rollbar connected to your Bitbucket Git repo, the stack trace entries become URLs linking to the exact line of code in source file.
When troubleshooting critical, customer-facing errors, developers can jump immediately from stack trace to source code, saving valuable time when every second counts.
Correlate Errors to Deploys
It’s easy to notify Rollbar every time you deploy to production or release a new version of your app. Rollbar integrates with Bitbucket Pipelines, and you can easily track deploys with other tools. Tracking deploys unlocks several valuable features in Rollbar that will make root cause analysis easier.
With deploy tracking enabled, Rollbar will tell you which deploy preceded the first occurrence of an error, or a re-occurrence of an error that was previously fixed.
View deployment details
Rollbar’s Deploys view provides a quick summary of all your recent deploys, including who triggered the deploy and what changes were included. This information can speed up root cause analysis when a recent change led to a spike in errors.
Visualize deploys and errors across time
When deploys are tracked in Rollbar, they will appear in project and error-level timelines that show error frequency across the last few minutes, hours, and days.
With deploys displayed on these charts, you can quickly confirm if a particular deploy caused a spike in errors.
Track Rollbar errors with Bitbucket issues (JIRA too)
Production apps often have more errors than developers can fix immediately. To ensure that nothing slips through the cracks, Rollbar errors can be linked to Bitbucket or JIRA issues.
Issues in Bitbucket and JIRA can be automatically or manually created from Rollbar, or a Rollbar error can be linked to existing issues. When Rollbar errors are resolved or reopened, the corresponding Bitbucket or JIRA issue is updated.
For teams using JIRA Cloud, the Rollbar for JIRA add-on surfaces real-time error frequency data in JIRA and also updates Rollbar error status when JIRA issues are updated for complete 2-way status sync.
See Rollbar in action with Hipchat, Bitbucket and JIRA
Rollbar integrates with Hipchat, Bitbucket, and JIRA so developers can get notified, investigate, and keep track of critical production errors with the tools they use every day. Check out the Rollbar + Atlassian page to watch a quick video and sign up for a 14-day free trial.
By Claire Maynard on January 3, 2017
If you didn’t hear it already, Bitbucket recently announced Pipelines which lets your team automate the integration and delivery process. Automation in software development is becoming increasingly important. Automation saves you time because you have less manual work and it reduces risk by giving you a consistent and repeatable process for all of your team’s code. Ultimately, you spend less time putting out fires and more time releasing quality code, faster.
While in most cases, your team will want to use automation to trigger builds when branches are pushed, there are times when you may want to add a manual step to your process, such as with longer-running builds or triggering a release manually.
That’s why we’ve added manual pipelines.
Trigger builds manually
Just add a custom pipeline to your bitbucket-pipelines.yml and you’ll be able to trigger it for a commit in Bitbucket.
Trigger builds with tags
Many of those already using Pipelines have asked for this, and we listened! In addition to letting you set up manual pipelines we’ve also introduced an additional way to trigger your builds — with tags.
You can now trigger your builds with tags in your Git repository (and bookmarks for Mercurial repositories). While your usual development workflow may mean pushing branches, your team might use tags to a commit for release. For example, configure a pipeline that deploys on tags then tag your commit to deploy it. Additionally, the name of the tag being built will be available as an environment variable as <$BITBUCKET_TAG>.
– npm install
– npm test
– npm install
– npm test
– npm publish ./
Check out our guide on how to trigger builds with tags.
Try Bitbucket Pipelines
If you’re ready to get started with Bitbucket Pipelines, sign up for a Bitbucket cloud account.
If you’re already using Pipelines, you can learn how to set up manual-triggered and tag-triggered builds here. Have feedback for us on these features? Tell us what you think by tweeting us @Bitbucket.
The Bitbucket Pipelines Team
By Amber Frauenholtz on December 13, 2016
2016 has certainly been a year for the books. All year long the Bitbucket Server & Data Center team has been improving Bitbucket and . You told us that modern software developers require tools that are reliable, let move fast, and build with high quality. We took your feedback to heart and built features that enable collaborative development without sacrificing speed or performance.
One hundred customer suggestions resolved, 100+ Bitbucket T-shirts printed, and thousands of cups of coffee consumed is one way to describe 2016 for Bitbucket Server, but that only scratches the surface.
To celebrate the launch of our final release in 2016, we thought it only fitting to review our development stats and favorite new features of the year.
Bitbucket Server team landscape
Our Bitbucket team was busy coding, designing, and documenting throughout the year. Here’s a at some of our most interesting stats.
Favorite new features
A year in review post wouldn’t be complete without a look at our most memorable features. From boosting performance for geographically dispersed teams to creating an unrivaled pull request workflow we did something for everyone.
- Sped up clone & fetch times for remote teams with smart mirroring for Bitbucket Data Center
- Added support for storing large binary assets with Git LFS
- Saved developers time by automatically transitioning JIRA issues with smart commits
Pull request progress became easier to track with reviewer status
Resolved one of our most requested feature suggestions with code search across projects and repositories
Streamlined the code review process with iterative reviews
The end of a busy year
In the software development world, every new year brings about new technologies and ways of working. Since Bitbucket Server’s beginning in 2012 it has been our privilege to find creative and thoughtful ways to make these changes available to you. Bitbucket Server 4.12, available today, caps off a year full of releases that do just that – bring modern software development to professional teams.
As 2016 comes to an end, we’d like to send a big thank you to all of our customers. You are the reason we get to do what we love every single day.
Start the new year off right and upgrade to Bitbucket Server 4.12 today.
Try Bitbucket Server 4.12
By Ben Echols on December 5, 2016
Your master branch represents the code that you will ship to your customers, and should be protected at all costs. No one intends to ship a bug to a customer on purpose, so having a mechanism in place to catch these subtle bugs is essential to a development team. Code review has been around in some form since the dawn of version control to help keep a close eye on the master branch and ensure code quality is high.
Pull requests in particular provide a way to do peer code reviews and merges as part of a branch-based development workflow. As teams grow sometimes you need to take pull requests a step further to really make sure code is ready to be merged in to the family jewel: the master branch.
Merge Checks in Bitbucket Cloud
That’s why we added merge checks to Bitbucket: they make it easy to ensure that every Pull Request is fully vetted before it gets merged. This gives teams the flexibility to:
- Require a certain number of approvers: get at least 1 additional set of eyes on any change before it is merged. (On the Bitbucket Cloud team, we require 2 approvals for every Pull Request.)
- Require a certain number of successful builds: Peer reviews are great but take that extra step and make sure the builds are passing pre-merge. Everyone says don’t break the build, but do you mean it?
- Require all tasks to be completed: those tasks are there for a reason. Make sure all the feedback reviewers leave gets addressed, instead of promises to fix it later.
- Reset approvals when the source branch of a pull request is modified: along with required approvers, this guarantees that no change goes unreviewed. This can be overkill for some branches, where reviewers can approve a PR while trusting the author to make some small tweaks, but it’s great for making sure nothing slips into a critical branch (typos in the release branch, anyone?).
Atlassian is a public company, so the Bitbucket team uses these checks as part of our compliance controls to prevent unauthorized changes to our code, and we know many teams have similar requirements. We also know that having an entire repository locked down can be frustrating, which is why we made merge checks totally configurable at the branch level. Production code can be protected and thoroughly reviewed but until it’s ready, you can still iterate quickly on features in dev and staging, all in the same repository.
Try Merge Checks
Merge checks are a feature in Bitbucket Cloud’s Premium plan which has features for teams that require granular admin controls, security and auditing. All features in Bitbucket Cloud’s premium plan are in a free trial until early 2017 when the plan will be $5/user/month.If you’re ready to get started, sign up for a Bitbucket Cloud account.
If you’re already using Bitbucket Cloud, you can add merge checks from your repository settings menu, under the branch permissions section.
Get started for free
Have more specific questions about this post? Reach out to us on Twitter to get the information you need