Last year at AtlasCamp we shipped a new integration framework named Bitbucket Connect. Unlike traditional REST APIs, Connect allows you to embed new pages and features directly within the Bitbucket UI via securely signed iframes. It’s kind of like OpenSocial, but with less XML and a far deeper integration with Bitbucket’s feature set. We’ve been using Connect internally to build out new features like Bitbucket Pipelines as independent, full-stack microservices. But even cooler than that: Bitbucket fans have been busy shipping their own user-contributed features to the Bitbucket add-on directory!
Here are six of my favorite Bitbucket features that teams outside of Atlassian shipped this year:
Kanban boards for Bitbucket
Two teams have independently built Kanban-style boards for managing your Bitbucket issues. Kanban boards are great for teams, as you can quickly see which team members are assigned to which issues, and what state the issues are in. Boards also allow users to easily update issues as they progress through your workflow.
Bucket Board provides a simple drag-and-drop board with your issues organized into columns by status:
I typically stick to a simple three column layout, but Bucket Board allows you to configure which status columns are visible based on your workflow needs.
Canvas for Bitbucket is another add-on that provides drag-and-drop boards. It has a few extra features, including BBQL-powered quick filters to restrict which issues are displayed, and the ability to map columns and swimlanes to arbitrary issue attributes:
You can have both add-ons installed at the same time, so try ’em out and see which one suits your team best.
Bitbucket has a slightly hidden feature that allows you to expose a repository’s contents as a static website. A couple of Seattle-based developers decided they could do better, and built Aerobatic: a GitHub Pages-style static site deployment engine on top of Bitbucket.
Aerobatic supports automatic building of Jekyll sites from any branch in your repository, just like GitHub Pages. Unlike GitHub Pages, they also support Jekyll plugins, Hugo, Wintersmith, and arbitrary npm builds for your site. Aerobatic also have a neat feature where you can serve multiple branches from the same repository on separate subdomains, so you can stage changes to your project’s website before pushing them to production.
Aerobatic do ask a modest fee for their services, but they’ll give you two sites for free (making it a great place to host your personal blog).
As you may have gathered, Bitbucket’s core focus is professional teams. As such, we’ve focused our backlog on features like branch permissions, performance, and perfecting the pull request experience; rather than some of the more fun social features like contributor statistics. Statistics are great for open source projects, and are a handy way to quickly see who has contributed to a particular project. However they’re less useful (or sometimes even dangerous, in the wrong hands) in a professional context: LOC, blame, and commit counts aren’t a great way to measure developer productivity.
But if you dig charts, you’re in luck! A small team of developers from Belarus have shipped some pretty sweet looking charts for Bitbucket. Awesome Graphs (a port of a popular Bitbucket Server add-on) gives you contributor statistics, commit volume over time, and a punch card chart showing what times of day your team is committing code:
Platform.sh is a PHP PaaS that monitors your Bitbucket repositories and deploys the head of each branch to a separate staging environment for testing. This is handy for quickly sharing your work with clients or teammates. It also means pull request reviewers can simply click a link to do some exploration testing of your new feature, rather than having to pull and deploy your code themselves.
For better or worse, I don’t PHP these days, though last I checked ~20% of Bitbucket repositories where the owner had declared a language were PHP. However if someone was interested in building or integrating a Node.js PaaS with Bitbucket Connect I’d be very interested in chatting 😉 Lucky for me, Platform.sh now supports Node.js, Ruby, and Python as well!
The team behind Awesome Graphs also shipped File Viewer for Bitbucket: an add-on that uses Bitbucket’s File View API to render PDFs, CSVs, GeoJSON, and 3D models. Their latest update includes experimental support for the powerful AutoDesk Forge viewer, which lets you rotate, measure, and explode 3D objects tracked in your Git repositories:
I’m blown away by the high quality of the features that Atlassian didn’t ship on the Bitbucket Connect platform. If these seem useful for your software projects, check out the Bitbucket add-on directory for a more complete listing of the neat features and integrations available for your Bitbucket account. You’ll need to sign up for a free Bitbucket account (if you haven’t already!)
Following the recent release of U2F support, we’re excited to introduce even more security-related improvements. Over the last few weeks, we rolled out an entirely new SSH stack for Bitbucket Cloud. In addition to our goals of increasing reliability and improving performance, the new infrastructure unlocks some security improvements that many of you been asking for. Today we’re pleased to announce support for the following features:
These improvements are available to all users starting today. The new stack also gives us more visibility into performance of different parts of the SSH process, enabling us to detect performance issues and opportunities for improvement more quickly.
Stay tuned for a follow-up post detailing what we learned from the development and deployment of the new SSH infrastructure. In the meantime, upload your key to get started.
New to Bitbucket Cloud? No problem! Sign up here and enjoy these new features in Bitbucket Cloud.
Several months ago, we released Bitbucket Pipelines Beta to offer a unified and centralized software development workflow for teams looking for continuous delivery solutions within Bitbucket Cloud. Since launch, we’ve gotten a lot of great feedback, and many have benefited from moving faster without losing product quality. In this post, we’ll provide a deeper look at the technical details of Pipelines that makes it such a valuable tool for teams.
Read on to learn more about Pipelines and our latest feature addition, team variables.
Configuration as code for reproducible environments
Getting started with Bitbucket Pipelines is easy. You can enable it in one click and define the build commands your team wants to run in a bitbucket-pipelines.yml configuration file that’s placed at the root of your repository. Bitbucket Pipelines will then start building your commits automatically and publishing the results straight into Bitbucket on every push. Having your team’s pipeline configured as code living in the source code repository not only makes it easy to modify your pipeline but also ensures that the build configuration is aligned and evolves together with the code.
The configuration file will also enable your team to define different build configurations per branch. This way you can seamlessly integrate your build automation with the branching workflow your team is using. Run your unit tests on all of your feature branches and let Bitbucket Pipelines deploy your app when changes are pushed to your production branch.
- echo "This script runs only on commit to the master branch."
- echo "This script runs only on commit to branches with names that match the feature/* pattern."
- npm install
- npm test
- echo "This script runs only on commit to the production branch."
- pip install awscli
- aws --region us-east-1 s3 sync site s3://my-bucket
Save time with fast development feedback
Fast development feedback plays an important role in continuous delivery. It helps by detecting test failures and deployment issues earlier in the process, which leads to shipping products faster. Since Bitbucket Pipelines is built within Bitbucket, it starts building your changes as soon as you’ve pushed them. While your build is being executed, you can track the progress with the logs streaming in real time. In case of a failure, logs will automatically expand the command that failed so you can quickly tell or make a strong guess about the root cause. The build status is also visible at all other places you care about: on commits, branches and pull requests.
When reviewing a pull request you can immediately see your build status in context and click through to find out more about the test failures – all without leaving Bitbucket.
Also, with the latest updates to the Bitbucket dashboard you can now easily filter out pull requests that have failing builds. This way you will avoid wasting time reviewing the code that broke tests. You can instead focus on reviewing the code that actually passed automated quality checks while the broken builds are being fixed.
Use Docker as a build environment
Bitbucket Pipelines uses Docker containers, which makes it possible to create flexible build environments. Docker uses versioned images to define these environments and you can specify the Docker image Bitbucket Pipelines should use when setting up your bitbucket-pipelines.yml file.
As an example, if you have a Node application, select the node:5.10 Docker image as the environment in which Bitbucket Pipelines builds should run:
You can also create your own Docker image for a fully customized build environment if none of the available Docker Hub images match your build requirements. Bitbucket Pipelines supports both public Docker repositories as well as privately hosted registries.
Apart from the flexibility benefit of running builds in Docker, it is also easy to spin up a Docker container locally. This will allow you to locally reproduce the exact build environment in which your Bitbucket Pipelines builds are executed. Such reproducible build environments can be a huge time saver when debugging failed builds. All you need to do is to spin up the Bitbucket Pipelines build container locally and study the result.
Newly added team variables to Bitbucket Pipelines
We’ve recently added team variables to Bitbucket Pipelines. Prior to adding this feature, if one had to block the access of a specific team or individual to a certain repository, they had to go with per repository access level variables which was repetitive and very time consuming, especially for bigger teams. If there were any changes (i.e. AWS keys), every single repository had to be updated one by one. Team variables make it possible to set up credentials once and for all. They make it possible to create environment variables at the team level and share or reference them in individual projects.
Above are only few of the many features of Bitbucket Pipelines (Beta). This is a big step forward towards the future of development tools in the cloud that are ready to use with a simple click and no infrastructure requirement. Sign up for early access to Beta!
Whether you’re burning the midnight oil at a startup or starting a new project within a larger organization, we want to be part of your Git journey. And in order to do that, we need to be there from the start. So Bitbucket Data Center now offers source code collaboration for professional teams, across any distance, whether your team is small or large.
Keep reading to learn more about what Bitbucket Data Center can offer any team, and how you can grow with Atlassian products.
Bitbucket Data Center is a next generation Git solution
When tools are mission critical to your work, you can’t afford any downtime. It doesn’t matter if your team is made up of 25 or 2,500 people; what matters is that your team can do what needs to be done without worrying about outages. This makes a deployment option like Bitbucket Data Center the solution for teams of all sizes and working together across the globe.
Fo example, if your Git solution gets hit with multiple users and clients (think CI/CD) then you need a highly available tool. Bitbucket Data Center is the only Git solution with out-of-the-box active-active clustering, which provides uninterrupted access to your source code even during an unexpected outage with zero downtime.
For distributed and/or large teams, Bitbucket Data Center provides features like smart mirroring and Git LFS (Large File Storage) to help with performance. Let’s look at a team at Atlassian that fits this bill. The JIRA Software team has teams located in Sydney, Australia and Gdansk, Poland. In a typical workday it’s common for a developer in Gdansk to need access to a repository hosted in Sydney. Instead of having to wait hours to clone the repository, the developer in Gdansk can clone and create a branch from the mirror that we have set up in Gdansk within just a few minutes because of our Git mirroring. By speeding up clone times, our teams aren’t worried about lost development time and can work more efficiently across countries and continents.
Git LFS, on the other hand, is meant for teams that work with large media assets like images and videos. At Atlassian Git LFS helps our designers, tech writers, and build engineers to be more productive when working with developers, because assets can be versioned in Bitbucket Data Center. This means that developers don’t need to shoulder tap or leave their code when working with assets like videos or audio files, because they have the information they need to make exceptional UI experiences at scale. As software development moves more and more into the direction of distributed agile development and even into the land of apps that require large files and slick designs, it’s a necessity for tooling to support various ways of working.
Bitbucket Data Center offers the only solution with default reviewers
Reliability is not the only reason why teams can grow with Bitbucket Data Center. It’s a combination of using highly available tools and features that help teams move fast. A small team might be tired of hearing “We need to move faster,” and a mid-size team might feel the pains of “Our team is growing and we need a more sophisticated way to manage our source code.” Wherever you fall on this spectrum of size, everyone should have the same access to features that help them get what needs to be done, done.
Pull requests are a great example of a feature in Bitbucket Data Center that help teams innovate, because they’re set up to yield quick turnaround times for code reviews and help teams ship faster and deliver value quickly to customers. Pull requests are also set up to include default reviewers and commit-level review. The commit-level review, for example, shows comments within a pull request, so reviewers can see what changes are being made through a code review.
But pull requests are not the only feature built around teams and collaboration. At Atlassian, smart commits give developers the ability to transition JIRA Software issues by embedding specific commands into a commit message from the source code. Developers also use code search to search code to find exactly what they’re looking for, right from the search bar. Pull requests, smart commits, and code search are especially important as your instance, project, and teams grow to keep organized and moving quickly.
Bitbucket Data Center integrates and can be built upon
Besides high availability and features that help growing teams collaborate, Bitbucket Data Center can act as a development platform by setting up integrations. If your team uses existing Atlassian tools, like JIRA Software and Bamboo, you can set up Bitbucket Data Center with these tools for full traceability and continuous integration or continuous delivery.
The Atlassian marketplace, offers hundreds of add-ons to meet your team’s needs outside of integrations with Atlassian tools. Integrations are important to any team and a Git solution needs to support end users, Applinks with other Atlassian tools, API calls, and/or WebHooks without slowing down response times. So the sheer number of end users becomes only one part of a larger story of your greater ALM solution (Application Lifecycle Management) no matter how small or large your business is.
By adopting Bitbucket Data Center as a small team, from day one, you are working with a solution designed for professional teams and rooted in team collaboration. This tool is also now meant to grow with your business as your team grows, wherever you are in the world.
Developers use pull requests to review code and ship quality software at speed. They’re core to the software development process of many teams. Getting to that relevant pull request (aka PR) is important to get your work done in time. But finding your PRs in Bitbucket Cloud hasn’t been easy. Currently, you need 5 clicks (yes, we counted) before you discover that PR you’re looking for. That’s unacceptable!
What if PRs were front and center on your dashboard in Bitbucket Cloud? Today, we’re launching a new personalized dashboard that will list all the PRs that you’ve been asked to review and the PRs you’ve created, across all repos, in one single place. So, that PR you’re looking for is just a click away.
In this new personalized dashboard:
On the top left, you’ll find the open PRs on which you’ve been added as a reviewer, along with other reviewers, their approvals, comments, and tasks.
On the bottom left, you’ll find a list of open PRs you’ve created, with the same details.
On the far right, you’ll find your recently updated repositories.
We know staying on top of code review discussions is key, so we added a blue dot on the PR comments to indicate when there are new comments since the last time you looked.
If you’re not using PRs, don’t worry – the personalized dashboard will only list your recently updated repositories. And don’t forget that the full list of your repositories is just a tab away.
We’ve been dogfooding the new personalized dashboard internally at Atlassian for the last month, and in that time, we’ve noticed our software teams clean up old pull requests faster and reduce code review time significantly! No more bookmarking the PR list page of individual repos and no more wasted time to find that damn PR.
We’re gradually rolling this out to all our Bitbucket users, but if you cannot wait and want to turn it on today, just head over to the Labs menu in Settings.
New to Bitbucket Cloud? No problem! Sign-up here and enjoy the personalized dashboard in Bitbucket Cloud.
Git and Mercurial are the two popular distributed version control systems in use today. There are many reasons for choosing one over the other, but they each do their job very well, and we’re thrilled to support both in Bitbucket Cloud. Bitbucket Cloud is the only, and the largest, hosting service that supports Mercurial. We’re very excited to announce today that Bitbucket Pipelines, the continuous delivery feature within Bitbucket, supports Mercurial now.
Bitbucket Pipelines lets your team build, test, and deploy from Bitbucket. It’s built right within Bitbucket Cloud, giving you end-to-end visibility from coding to deployment. We initially launched Bitbucket Pipelines Beta with Git support only, but thanks to the enthusiastic feedback from our Mercurial users interested in continuous delivery, we decided to implement support for Mercurial as well.
We’re excited that both our Git and Mercurial users are able to run Bitbucket Pipelines today. Sign up and get early access to the beta if you haven’t done so already!
Not a Bitbucket Cloud user? Start here by creating an account.
Just after 18:00 UTC 19 July 2016, we published our first set of AAAA records in DNS, making bitbucket.org and its associated hostnames available to the world over IPv6. We’re taking a dual-stack approach here, so IPv4 addresses will continue to work for the foreseeable future – but any IPv6-only systems you manage will now be able to access Bitbucket APIs and repos, and any systems that work with both IPv4 and IPv6 will have additional routing options which may improve network performance. This also makes it easier for us to handle new networks and clients, especially as new IPv6-only systems come online.
IPv6 traffic picked up as soon as DNS servers started seeing AAAA records.
Most people will not have to do anything different to use our IPv6 addresses: in fact, if your local network and ISP both support IPv6, then you may already be using IPv6 to reach Bitbucket. However, some people may need to update their firewall configurations to permit the following destination IPv6 addresses for bitbucket.org:
Firewalls should also permit the following destination IPv6 addresses for api.bitbucket.org:
These addresses are listed alongside their IPv4 equivalents in our public documentation. We’ve also added IPv6 support for altssh.bitbucket.org, 2401:1d80:1010::15f and 2401:1d80:1003::15f, in case you need those, and set up forward and reverse DNS for all of our allocated IPv6 addresses.
Our IPv6 work started as a ShipIt project by some members of our Network Engineering team, using a proof-of-concept implementation on Bitbucket in a live demo. We had to perform a number of network and infrastructure upgrades (including new IPv4 addresses) before we could start using IPv6 for real, but once those upgrades were done we moved pretty quickly through testing, preparation, and deployment.
The best part of this whole IPv6 rollout, though, is that nobody would have noticed it if we hadn’t said anything. The Happy Eyeballs algorithm has done much of the heavy lifting here, seamlessly moving millions of sessions to IPv6. Our support team has seen a couple of tickets about IPv6-specific routing difficulties, but they were able to resolve or work around the issue within minutes. (If you’re also having problems due to IPv6 routing, then please contact us at firstname.lastname@example.org for assistance.)
We’re very glad that this has gone so well, and that we can take the lessons we’ve learned deploying IPv6 to Bitbucket and apply them to other Atlassian products. Stay tuned for more updates on infrastructure projects!
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.
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.
In recent years software teams across all industries have adopted Git thanks to its raw speed, distributed nature and powerful workflows. Additionally, modern software teams are increasingly cross-functional and consist not only of developers but designers, QA engineers, tech writers, and more. In order to be successful these teams need to collaborate not just on raw source code but on rich media and large data.
It’s no secret though that Git doesn’t handle large files very well and quickly bloats your repositories. We are therefore excited to announce that, following Bitbucket Server’s lead earlier this year, Git LFS is now available in beta for Bitbucket Cloud to improve the handling of your large assets. So even if your files are really, really large, Bitbucket Cloud allows your team to efficiently store, version and collaborate on them.
Why should you care about Git LFS?
Git was optimized for source – it’s easily merged and compressed and is relatively small, so it is perfectly feasible to store all history everywhere, but this makes it inefficient and slow when trying to track large binary files. For example, If your designer stores a 100 MB image in your Git repository and modifies it nine times, your repository could bloat to almost 1 GB in size, since binary deltas often compress poorly. Every developer, build agent, and deploy script cloning that repository would then have to download the full 1 GB history of changes, which may lead to drastically longer clone times. Just imagine what would have happened if your designer made 99 changes to that file.
A common solution to this inherent flaw in Git is to track these large files outside of Git, in local storage systems or cloud storage providers, which leads to a whole new set of problems. Separating your large files from your repository will require your team to manually sync and communicate all changes to keep your code working.
With the addition of Git LFS support, you can say goodbye to all these problems track all your files in one place in Bitbucket Cloud. Instead of bloating your Git repository, large files are kept in parallel storage, and only lightweight references are stored making your repositories smaller and faster. The next time your team clones a repository with files stored in Git LFS, only the references and relevant large files that are part of your checked out revision will get downloaded, not the entire change history.
For those interested in a longer explanation of how Git LFS works and how to migrate your existing repository, watch this presentation by Tim Pettersen, Atlassian Developer Advocate, on Tracking huge files with Git LFS.
When is Git LFS right for you?
Generally, if you want to use Git to easily version your large files, Git LFS is the right choice. To call out just a few cases in which Git LFS will make your life easier, here’s a short list:
Game developers working with large textures, 3D, audio and video files
Mobile developers catering for higher and higher display resolutions
Web developers building pages with rich media
Software teams handling checked in dependencies
Researchers working with huge data sets
Multimedia producers and designers
QA engineers using database snapshots for functional tests
Technical evangelists who store their presentation slides in Git
Git LFS support is built right into SourceTree
If you’re like us and use SourceTree, tracking files with Git LFS is one click away. Simply right click on any file type you’d like to track and select the “Track in Git LFS” option. SourceTree will do the rest for you.
What you will get with the Git LFS Beta
Track everything in one place – Track your large assets alongside your source code and stop worrying about manually versioning them in a separate storage system.
Store, version and share large files – Version all your large files with Git, no matter how large they are. With Git LFS you can store huge audio files, graphics, videos or any other binaries efficiently. During the beta period, you get 1GB of storage for up to 5 users. If you are a paid team your storage is based on your user tier.
Free up your repository – Store more in your Git repository. Git LFS stores your large files externally and keeps your actual Git repository lightweight.
Clone and fetch faster – Only download what you need. Git LFS will only fetch those large files that you check out and not the entire history of changes.
Just do git – No need to learn anything new. Git LFS seamlessly integrates into your Git workflow and does not require you to learn a new workflow, new commands or use new tools.
Git going right away
If you’re ready to get started, sign up for a Bitbucket Cloud account. If you’re already using Bitbucket Cloud, enable it in one click on the repos you would like to try it out on by heading to the “Git LFS Beta” section on the left sidebar.
The original post for this git cheat sheet lives here.
New to Git? Our Git cheat sheet saves you time learning Git commands without having to memorize them all by heart. We’ve included the basic Git commands, Git branches, remote repositories, undoing changes, and more advanced commands.