Add access keys to branch permissions in Bitbucket Server 4.14

By 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.

New guides for Bitbucket Pipelines

By on February 15, 2017

Community Guides

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 feature within Bitbucket. A ton of you wrote excellent tutorials about how you’ve configured your Pipelines for various 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 guides, making it even easier for you to set up Pipelines.

New Language Guides

If you’ve tried Pipelines before but had trouble configuring your .yml file for Java, Javascript/Node.js, Ruby, Python or PHP, or if you’re interested in trying Pipelines for the first time, we’ve created these five guides for you!

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.

Enjoy!

Haven’t tried Bitbucket Pipelines yet? Give it try!

 

Try Bitbucket Pipelines

 

We’ll be at Git Merge 2017!

By 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:

Squash commits when merging a Git branch with Bitbucket

By 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:

2017-01-17-17-34-57-1

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 merging a pull request:

git squash commits

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.

Update 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.

Try Squash-merges

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.

Bitbucket Server 4.13 brings in-browser editing and more

By 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.

 

anim_1400

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.

issues-pr-titles-email-1200px-v2

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.

Add tags to commits in Bitbucket

By 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 for an organization instead of just using branches, which commonly leaves you with lots of rarely used branches.

Here’s a look at a hypothetical scenario for adding tags: You’re a release manager getting ready for a release so you navigate to Bitbucket’s UI and view all the commits, looking for the one that has all the features you want to include and has passing builds. You find the commit and realize that it is missing a release tag, so you go to the command line – create and push the tag so you can tag the commit for the release, then go back to Bitbucket’s UI to view the tag and ultimately, do the release. This is a major pain (shakes fist at context switching).

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 annotated 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:

Add tags from Bitbucket’s UI

tag_ui_gif_640

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

 

Find & fix errors faster with Rollbar + Bitbucket

By 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.

Suspect Deploys
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.

screen-shot-2017-01-04-at-7-33-55-pm

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.

screen-shot-2017-01-04-at-7-29-52-pm

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.

screen-shot-2017-01-04-at-7-36-01-pm

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.

screen-shot-2017-01-04-at-7-37-52-pm

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.

 

2 additional ways to trigger your builds in Pipelines

By 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

manual-pipeline5

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 mark 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>.

image: node:4.6.0

pipelines:
default:
– step:
script:
– npm install
– npm test
tag:
release/*:
– step:
script:
– 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.

Cheers!

The Bitbucket Pipelines Team

Bitbucket Server: a year in review

By on December 13, 2016

hero-bitbucket-server-year-in-review

2016 has certainly been a year for the books. All year long the Bitbucket Server & Data Center team has been improving Bitbucket and adding new features you have requested. You told us that modern software developers require tools that are reliable, let them 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 peek at some of our most interesting stats.

bitbucket-server-year-in-review-v02

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.

January

distributedgit

March

Pull request progress became easier to track with reviewer status

May

bbserver-blog-600x-may2

Resolved one of our most requested feature suggestions with code search across projects and repositories

July

bbserver-blog-600x-july

August

merge

October

Stash38-aws

November

iterative review

Streamlined the code review process with iterative reviews

December

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

Protect your master branch with Merge Checks

By 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:

Bitbucket merge checks

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.

Happy coding!

Get started for free

Have more specific questions about this post? Reach out to us on Twitter to get the information you need