We are proud to announce the integration of several popular cloud IDEs into the Bitbucket experience. You are already managing, building, and deploying your code to the cloud; you can now code in the cloud as well. Your personally-configured cloud IDE and dev environments are now accessible to you on any machine anywhere, all connected to, and, most importantly, integrated with the familiar Bitbucket interface.

Today, we are launching integrations with Codio and Codeanywhere, since they meet Atlassian’s standards of quality and security. Integrations with other cloud IDE vendors will be available soon. You can now click on the repository view of Bitbucket to clone and edit files directly in Codio or Codeanywhere:

Cloud IDEs have come a long way in the past few years. The IDEs we have chosen to integrate with Bitbucket are solid, full-fledged development environments with desktop-quality coding experiences: resizing, context-coloring, navigation, and responsiveness. We believe that many developers will appreciate the code editing features, as well as the more advanced features of some of our partner cloud IDEs – automatic configuration of code libraries and build server & deployment integrations.

Cloud IDE integration is a one-click process. Just select the IDE partner of your choice from your Bitbucket users settings and authenticate. Bitbucket’s repository view page will now contain an additional option in the ‘develop’ menu: Open in your cloud IDE (‘Open in Codio’, for example).

More about our launch partners

Codio

Codio is the cloud-based IDE and publishing platform for teaching computer programming and computer science in schools, universities, and the vocational education sector worldwide.

“Codio has always focused on delighting users with instant access anywhere to a powerful web IDE, and with today’s integration we’re thrilled to extend that experience to Bitbucket.”

– Freddy May, CEO and founder, Codio.

Codeanywhere
Collaboration platform for developers. Codeanywhere’s powerful web IDE has all the features of a Desktop IDE but with additional features only a cloud application can give you.

“When Codeanywhere was just starting out, connecting to Bitbucket was one of the first feature requests our users had. Today I am ecstatic that Bitbucket will be integrating Codeanywhere, allowing their users to easily and seamlessly edit and write code, from anywhere.”

Congrats to the New England Patriots for winning the Super Bowl. And what a heartbreaker for fans of the Seattle Seahawks! But it was a very close game and it could have gone either way. Both teams have a lot to celebrate. Just like any good football team reflects on their accomplishments at the end of the season, the Bitbucket team has a lot to celebrate, too. So we thought it would be fun to look back at what we achieved together in 2014. Thank you for making 2014 our best year yet and here’s to making 2015 even better.

It’s been a busy quarter for us at Bitbucket. As you may have noticed, Bitbucket is faster than ever, and even more reliable for our human users, cloning agents, and even for our robot friends who reach on behalf of CI systems and other integrations.

We also have a bunch of new features that have launched recently. Here’s a recap:

Merged pull requests in compare view

It’s often useful to see the pull request history when comparing a branch to master, or between tags. In this way you could see all the features (and fixes) that have been pushed from, say ‘staging’ to ‘deployed’ versions of your application, shown as a list of pull requests.

A tab called ‘Merged Pull Requests’ now appears alongside the familiar ‘Diff’ and ‘Commits’ tabs on all Compare and Branch results to list any pull requests that have been merged into the source, and you can now examine each of these pull requests with a single click.

Introducing ‘Omnibar’

Sometimes you just can’t be bothered with your mouse. For the power users of Bitbucket, we’ve created the Omnibar, a one-stop shop for finding the things you want and taking action on them without ever having to leave your keyboard. Your repositories, pull requests, and issues are just a few keystrokes away. Just hit the period key to reveal Omnibar.

Ignore whitespace in diffs via URL

Depending on language and coder style, sometimes you do care about whitespace in diffs. But sometimes whitespace differences just clutter up the diff. Bitbucket now gives you the option to ignore whitespace in diffs.

Whenever you’re on a Bitbucket page showing a diff, you can add “w=1″ to the query string in the URL to force the diff engine to ignore whitespace when comparing lines. On reload, differences in the files where a given line has only unmatched whitespace will not be shown.

Custom tab size via URL

So, how wide should a tab be? It’s a matter of taste, and, if the discussions on our team are any example, of religious conviction. Now you can set all tabs in Bitbucket code displays to the width you believe is best by adding a “ts” query param to the URL and reloading the page.

For example, adding “ts=4″ to the query string of a URL will set the tab size to 4 spaces for all code on that page. The feature is currently supported in Chrome, Firefox, and Safari, but not Internet Explorer due to CSS limitations there.

Emoji Auto-complete

Sometimes, code comments, wiki pages, and readmes are just crying out for emoji. But who can remember ‘Face With Stuck-Out Tongue And Tightly-Closed Eyes?’ (表情(いー))

The many (many) emoji Unicode has to offer can now be entered in Bitbucket by ‘type-ahead’ when you type a ‘:’ followed by any part of the emoji description string (followed by a brief pause then pausing a bit). For example: typing ‘:ast’ will autosuggest a number of matching emoji including ‘:astonished:’ with the astonished face emoticon shown for your selection, ‘train’ will return all sorts of train emoticons.

Improved emoji

And, now, your emoji on Bitbucket are in high-res.

Bitbucket now supports the so-called ‘twemoji’ set used by Twitter and others, which cover the entire Unicode space with emoji in scalable, resolution-independent vectors. Previously, we were using a stagnant set of .png file emoji that simply scaled to twice their source size on high-dpi (including ‘retina’) screens, and didn’t map perfectly with modern Unicode characters. We render our new emoji set as native DOM images, and they look great in all modern browsers, including IE9.

[Editor’s Note: This is the first of a series of guest blog posts around Bitbucket. This post is written by Will Salcido, CEO & Co-Founder of Bedrock Analytics Corporation. If you are interested in writing a guest post about your usage of Bitbucket, or best practices & tips, please contact us at guestposts@bitbucket.org, and we will reach out to you.]

Will Salcido is the CEO & Co-Founder of Bedrock Analytics Corporation. Will spent over a decade in the field of analytics across several leadership roles at Nestle, Novartis, Ghirardelli & Lindt. He developed analytical software for Ghirardelli that led him to solo-deploy the solution across 11 European countries in 2011. Bedrock Analytics is a data visualization and analytics software company based out of Oakland, CA.

The idea for what would become Bedrock Analytics came to me while I was working in Stockholm, Sweden. After nine international deployments of the analytical solution I had built for Ghirardelli & Lindt, I discovered that nearly all consumer product companies had similar issues working with data. Bedrock’s data visualization software enables consumer product companies to extract actionable insights from retail data. The software fills a skills gap for small to midsized companies and makes larger enterprises more efficient by automating the discovery of insights. Our customer base of consumer product companies spans throughout North America, Central America, and Europe.

In the very beginning, we had a single person with access to the source code. It wasn’t until we started hiring additional engineering staff that we began exploring the different hosted repository providers. We tested a few options and after careful deliberation, we ended up choosing Bitbucket.

We chose Bitbucket since it allowed us to collaborate within our development team using the built-in wiki and the “pull request’ workflow, and had the ability to scale along with our company. We recently hired engineering talent in Eastern Europe and Bitbucket allowed us to manage our development projects in an efficient manner. Bitbucket has made it possible to segregate our code in ways that enabled different specialized teams to work in parallel on different portions of our source code while keeping everything organized in a single platform. Most importantly, we are also looking forward to integrating Bitbucket with other Atlassian and non-Atlassian products as we continue to grow.

Our engineers like the fact that Bitbucket offers unlimited private repositories to store smaller ongoing projects. Having the ability to track changes made in each repository has saved the team countless hours. We are in the middle of scaling our processes and Bitbucket has become a critical part of how we are gaining efficiencies within our development team.

The maintainers of the Git and Mercurial open source projects have identified a vulnerability in the Git and Mercurial clients for Macintosh and Windows operating systems that could allow critical files to be overwritten with unwanted files, including executables.

Because this is a client-side vulnerability, Bitbucket itself is not affected; however, we recommend you update your Git client with one of the published Git maintenance releases (1.8.5.6, 1.9.5, 2.0.5, 2.1.4 and 2.2.1) or Mercurial client with the latest release.

If you are also using SourceTree please follow these instructions to update your Git client:

Bitbucket helps teams build better software through collaboration. Our customers want tools they can trust and software that won’t break under stress or load. Robustness, reliability, and security are very important attributes of our software. But, like any other software, sometimes things may go wrong. Anticipating those situations and building good diagnostics and recovery features in the product is crucial.

Quality at Bitbucket

Our Bitbucket team doesn’t include an army of dedicated testers who would spend weeks before the release to find bugs. That’s inefficient and creates a sub-optimal split of responsibilities that leads to poor quality. Instead, we take a very different approach. Every developer on the team is responsible for the quality of the software. But not every developer is good at testing. That’s why we have a very small team of QA engineers whose primary goal is to enable every developer to do a better job with quality. It is usually achieved through the following tasks:

Developer education: Help the development team learn best practices for writing high-quality code.

Risk assessment: Think through all the possible scenarios that can cause the software to break and ensure that developers are aware of the highest-risk areas.

Trend analysis: Analyze bugs and support requests to spot scenarios that have caused problems, and find ways to prevent similar problems in the future.

Tool development: Provide test environments and new tools that help the development team ship high-quality software.

That’s why QA in our team stands for “quality assistance” and not “quality assurance”.

The challenges of scale

But it’s not that simple, especially if you’re building high-quality products at ever-increasing speed and scale with a small QA team. As Adrian Cockroft once said “scale breaks hardware, speed breaks software and speed at scale breaks everything!”. There are tons of problems to solve. Most importantly, there is a dire need for innovative approaches and tools.

Good engineering practices

In order to achieve our goals of building quality at scale we use some of the following tactics, which we are happy to share with the Bitbucket community:

Branching model – Follow a branching model using git that enables the use of pull requests for code reviews. Having a second pair of eyes looking at every code change helps spread the knowledge within the team and spot potential problems early.

Code documentation – Write code that is self-documenting and as readable as possible. This is crucial for effective collaborative work on the same codebase and helps new starters get up to speed with the code base quickly.

Internal Dogfooding – Demo new features to a large audience of internal users to solicit feedback from different software teams.We sometimes use new features and components for months internally before we release them to our customers.

Feature flags – Implement new features behind flags that allow us to roll them out slowly, starting with a small group of internal users at Atlassian, and then widening the audience to a segment of Bitbucket users.

“Blitz” testing – Use a coordinated, short (~1-2 hour) round of exploratory testing of a new product or feature(s) by a group of people from across the company. This gives us extra confidence that we definitely handled all those different use cases.

Right tools – Use static analysis tools to detect common coding problems. Track exceptions in real time in all of our environments and measure everything to ensure the entire system is working as expected.

This is just the tip of the iceberg. If you’re interested to learn more about how we do QA at Atlassian and if you’re in Austin, TX on 9th of December – join us for meetup and drinks. We’re also hiring, so check out this page if you’re interested.

As mentioned on Atlassian’s main blog, we’ve decided to end SSL 3.0 support on bitbucket.org in the wake of the newly-published POODLE exploit. Once all the facts were in, the choice was easy, and we acted quickly to address the issue. As our customer, though, you should know why we did what we did.

In the POODLE exploit, a well-placed attacker can trick each end of an SSL transaction into downgrading to an older, insecure, cipher. Once the connection is established, the attacker can become man-in-the-middle and compromise the data going back and forth between server and client.

The exploit relies on both ends’ willingness to communicate over SSL 3.0. If just one end of the transaction is unwilling to cooperate, then the attack fails altogether. Some older browsers or Git/Mercurial clients may not be able to use the newer TLS standard, though – so why did we choose to disable SSL 3.0 outright?

It’s the recommended solution to the problem.Möller’s paper describing the exploit goes into further detail here, especially regarding flaws in CBC block cipher padding, but the gist is that SSL 3.0 can no longer be trusted as an encryption mechanism; it’s fundamentally flawed, and it will not be fixed. The optimal solution is to disable SSL 3.0 on our end and force everyone to use some flavor of TLS instead.

It has minimal impact on our users. All of the browsers we support can handle the newer TLS encryption standard, as can most of the Git and Mercurial clients that communicate with our servers over HTTPS, and the change has no effect whatsoever on SSH connections.

It protects all of our users – even the ones whose stuff breaks because of it. We want to ensure that all of our users’ HTTPS sessions are unaffected by POODLE, so we’ve done the most effective thing to protect Bitbucket traffic from that particular attack (and a few others). We can’t protect our users from other sites, though, so if this change breaks your browser or client then (unfortunately) you need to upgrade ASAP.

The safety and security of your data are our #1 priority, so this change is effective immediately. If you need further assistance, then please contact us at support.atlassian.com.

HipChat notifications from Bitbucket are a great way to keep your team up to date on changes to their code repositories – no matter where they are. For example, your team can receive notifications in the HipChat room you use to collaborate whenever a commit is pushed to the repo. But of course, there’s a lot more happening on your repositories than just new commits. Issues and pull requests are a big part of your development workflow, so with our new HipChat add-on for Bitbucket, we’ve made it dead-simple to send notifications about those too.

Bitbucket’s new HipChat add-on includes the following notifications:

Commits: when a new commit is pushed, or commented on

Pull requests: when a pull request is created, commented on, merged, or declined

Issues: when an issue is created, updated, or commented on

Our new add-on is also easy to install and configure. Just look for ‘HipChat integration’ in the menu when managing your team or personal account. Once the add-on is installed, any administrator of a repository can configure notifications. Notifications can be added or configured when managing an account or managing a repository. When you manage your account, you will be able to view and manage notifications across all repositories owned by the account. When you manage a repository you will be able to view and manage notifications for that repository.

If you’re new to HipChat, be sure to check it out. HipChat is a hosted private chat service for your team. Share ideas and files in persistent group chat rooms, create a new room on the fly, video chat when you need to, share files seamlessly, and more.

If you frequently deliver apps to the cloud, you know every extra step to package and deploy your code introduces risk and can add hours to the process. Now, with Push-to-deploy support for Bitbucket, deploying changes to your application in App Engine is easy, safe and fast.

Pull requests in Bitbucket are a great way to share proposed code changes for review and get feedback from your team. Of course, this typically leads to discussions and feedback in comments, which might result in further changes to the code. While great for improving code quality, feedback via comments can get lost easily. Now, with pull request tasks, you can turn feedback into actionable tasks. Never miss a crucial change.

To create a task, select Create task within a comment and enter the task info. You can also highlight the relevant text to fill-in the info before you select Create task.

Once you create tasks, you no longer have to search through all of the comments on a pull request to find follow-up items. You can keep track of all open and resolved tasks with a consolidated list available from the top of a pull request.