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.
Last week, we released support for FIDO Universal 2nd Factor in Bitbucket Cloud. FIDO U2F is an emerging standard for two-step verification that uses a physical USB key to digitally sign a challenge from a trusted website. It’s a new authentication standard designed to enable small USB tokens, mobile phones, and other devices to act as a secure second factor for 2FA without requiring any additional overhead of installing drivers or client-side software applications.
What does this mean for you?
You may have heard about some high profile breaches and subsequent unauthorized publication of stolen user credentials in the past few weeks. Two-step verification on your Bitbucket Cloud account ensures that your data will continue to be protected even if someone else gets your password.
With U2F, instead of having to enter a TOTP (Time-based One-time Password) every time you want to log in to Bitbucket Cloud, you can simply press a button on a small USB device plugged into your computer. You are also less vulnerable to phishing attacks since security keys will only sign challenges that match the proper domain for the website.
Visit two-step verification settings to add your key. If you do not already have two-step verification enabled, you’ll need to enable it before you can use your U2F key with Bitbucket Cloud.
Special Yubikey promotion for Bitbucket users
You’ll need to purchase a security key that supports U2F in order to take advantage of this feature. We’re collaborating with Yubico, co-creator of the U2F protocol, and offering discounts for a limited time through a special offer: Bitbucket teams can purchase up to 10 keys at a 25% discount, (while supplies last). You can find more information about the offer here.
We are proud to be among the first few websites to support this standard. “We applaud Atlassian for their support for the FIDO U2F protocol, by introducing this forward thinking strong public key cryptography two-factor authentication option to their user base,” said Jerrod Chong, VP Solutions Engineering, Yubico. Earning and keeping your trust is part of our customer commitment. Learn more about 2FA and U2F.
Forget about having to remember multiple passwords and say hello to a better Atlassian experience in the cloud. Bitbucket users are now being upgraded to Atlassian account. The integration of Atlassian account with all Atlassian Cloud services is currently in progress, and when it is complete, you will be able to log in to Bitbucket, JIRA, Confluence, and HipChat with one Atlassian account. In addition, you can now use your Atlassian account to log in to SourceTree and our support and billing systems.
The upgrade process will ask you to verify the email address that we have on file. This should be quick and painless, and then it’s back to Bitbucket business as usual!
Already have an Atlassian account? No worries, we’ll join your Bitbucket account to your existing Atlassian account. And if you want to change your email address associated with your Bitbucket account, click “Try another email” during the migration process. If you use Google authentication to log in, you can keep doing so provided it matches your Atlassian account email address.
Want to learn more about Atlassian account? Click here.
Just a couple of months after version 2.8, Git 2.9 has shipped with a huge collection of usability improvements and new command options. Here’s the new features that we’re particularly excited about on the Bitbucket team.
git rebase can now exec without going interactive
Many developers use a rebasing workflow to keep a clean commit history. At Atlassian, we usually perform an explicit merge to get our feature branches on to master, to keep a record of where each feature was developed. However, we do avoid “spurious” merge commits by rebasing when pulling changes to our current branch from the upstream server (git pull −−rebase) and occasionally to bring our feature branches up to date with master (git rebase master). If you’re into rebasing, you’re probably aware that each time you rebase, you’re essentially rewriting history by applying each of your new commits on top of the specified base. Depending on the nature of the changes from the upstream branch, you may encounter test failures or even compilation problems for certain commits in your newly created history. If these changes cause merge conflicts, the rebase process will pause and allow you to resolve them. But changes that merge cleanly may still break compilation or tests, leaving broken commits littering your history.
However, you can instruct Git to run your project’s test suite for each rewritten commit. Prior to Git 2.9 you could do this with a combination of git rebase −−interactive and the exec command. For example:
git rebase master −−interactive −−exec=”npm test”
would generate an interactive rebase plan which invokes npm test after rewriting each commit, ensuring that your tests still pass:
pick 2fde787 ACE-1294: replaced miniamalCommit with string in test
exec npm test
pick ed93626 ACE-1294: removed pull request service from test
exec npm test
pick b02eb9a ACE-1294: moved fromHash, toHash and diffType to batch
exec npm test
pick e68f710 ACE-1294: added testing data to batch email file
exec npm test
# Rebase f32fa9d..0ddde5f onto f32fa9d (20 command(s))
In the event that a test fails, rebase will pause to let you fix the tests (and apply your changes to that commit):
npmERR!Test failed. Execution failed: npm test You can fix the problem, and then run
git rebase −−continue
This is handy, but needing to do an interactive rebase is a bit clunky. As of Git 2.9, you can perform a non-interactive rebase exec, with:
git rebase master -x “npm test”
Just replace npm test with make, rake, mvn clean install, or whatever you use to build and test your project.
git diff and git log now detect renamed files by default
Git doesn’t explicitly store the fact that files have been renamed. For example, if I renamed index.js to app.js and then ran a simple git diff, I’d get back what looks like a file deletion and addition:
A move is technically just a move and a delete, but this isn’t the most human-friendly way to show it. Instead, you can use the -M flag to instruct Git to attempt to detect renamed files on the fly when computing a diff. For the above example, git diff -M gives us:
diff −−git a/app.js b/app.js
similarity index 100% rename from index.js rename to app.js
What does -M stand for? renaMes? Who cares! As of Git 2.9, the git diff and git log commands will both detect renames by default, unless you explicitly pass the −−no-renames flag.
git clone learned −−shallow-submodules
If you’re using submodules, you’re in luck – for once! 🙂 Git 2.9 introduces the −−shallow-submodules flag that allows you to grab a full clone of your repository, and then recursively shallow clone any referenced submodules to a depth of one commit. This is useful if you don’t need the full history of your project’s dependencies. For example, if you have a large monorepo with each project stored as a submodule, you may want to clone with shallow submodules initially, and then selectively deepen the few projects you want to work with. Another scenario would be configuring a CI or CD job that needs to perform a merge: Git needs the primary repository’s history in order to perform its recursive merge algorithm, and you’ll likely also need the latest commit from each of your submodules in order to actually perform the build. However you probably don’t need the full history for every submodule, so retrieving just the latest commit will save you both time and bandwidth.
Overriding .git/hooks with core.hooksPath
Git’s comprehensive hook system is a powerful way to tap into the lifecycle of various Git commands. If you haven’t played with hooks yet, take a quick look at the .git/hooks directory in any Git repository. Git automatically populates it with a set of sample hook scripts:
$ ls .git/hooks
Git hooks are useful for all sorts of things, for example:
a pre-commit hook can verify that your tests are passing before allowing a commit to be created
However, up until now, hooks have had a big administrative drawback: you have to copy or symlink them into the .git/hooks directory for every repository you want to apply them to. Git 2.9 introduces a new core.hooksPath config property to override the location of your hooks directory. So:
git config core.hooksPath /etc/git/hooks
will configure your current repository to check for hooks in /etc/git/hooks, or:
git config −−global core.hooksPath /etc/git/hooks
will let you centrally manage hooks for all of your local repositories.
git commit learnt to be permanently verbose
Do you ever invoke git commit and then stare blankly at vim trying to remember all the changes you just made? The verbose flag is for you!
Ah crap, which dependency did I just rev?
# Please enter the commit message for your changes. Lines starting
# with ‘#’ will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with ‘origin/master’.
# Changes to be committed:
# new file: package.json
you can invoke git commit −−verbose to view an inline diff of your changes. Don’t worry, it won’t be included in your commit message:
Bump left-pad to 1.1.0
# Please enter the commit message for your changes. Lines starting
# with ‘#’ will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with ‘origin/master’.
# Changes to be committed:
# new file: package.json
# −−−−−−−−−−−−−−−−−−−−−−−− >8 −−−−−−−−−−−−−−−−−−−−−−−−
# Do not touch the line above.
# Everything below will be removed.
diff –git a/package.json b/package.json
index 28bcfc7..825e958 100644 −−− a/package.json +++ b/package.json @@ -31,7 +31,7 @@
“@atlassian/gulp-atlassian-soy”: “^2.0.6”, – “left-pad”: “1.0.3”, + “left-pad”: “1.1.0”,
The −−verbose flag isn’t new, but as of Git 2.9 you can enable it permanently with git config −−global commit.verbose
git merge will no longer merge unrelated histories
It’s possible to have multiple branches with completely separate root commits — and therefore separate histories — within the same repository. There are a few good reasons for this, for example: in Bitbucket you can store your project’s documentation on its own branch and serve it as a static website using Aerobatic; or you may have rewritten your master branch to use Git LFS in order to reduce the size of your repository. Regardless, if you or one of your colleagues accidentally ran git merge on two unrelated branches in your repository, it would have some bad consequences for your team. In the former case, your documentation would be quietly merged into your code. In the latter, you’d probably just end up with a horrific set of merge conflicts.
Regardless, merging unrelated histories in Git 2.9+ is a non-issue because git merge won’t let you. Unless you explicitly pass the −−allow-unrelated-histories flag. So, uh, don’t do that!
There’s plenty more!
These are just six items from a list of over a hundred features, fixes, and performance improvements shipped by the Git wizards in version 2.9. Check out the release notes for the full scoop, and then download the latest version or upgrade using your favorite package manager.
Thanks for reading! If you want to chat Git, Bitbucket, or JIRA arcanery please hit me up on Twitter: I’m @kannonboy.
Keeping your code secure is crucial. That’s why last year we added support for 2-factor authentication. However, only having native 2FA support limits you from accessing Bitbucket repositories via 3rd party applications. Today, we’re excited to announce application-specific passwords (a.k.a. app passwords), which will allow you to just do that. App passwords let applications access Bitbucket’s API via HTTPS when 2-factor authentication is enabled on your Bitbucket account.
For example, you can use an app password in SourceTree to get full desktop access to your repositories when you have 2FA enabled. From the command line, you can make API calls with the app password instead of the account password, like:
You can set the scope of app passwords when you create them and give each application exactly the access it needs. We show you the last time each app password was used to access Bitbucket, and if you want, you can easily revoke an app password if something changes.
Software has changed the world faster than almost any other industrial innovation and it’s only picking up speed. Companies are moving from infrequent, large code deployments to frequent, small and agile deployments. This trend is having a huge impact on the current software development processes. For example, in one of our most recent customer surveys, more than 65% of software teams noted that they are practicing some form of continuous delivery. It’s becoming the norm for software teams.
But implementing continuous delivery is not easy. Setting up build agents is complicated. Developers have to constantly juggle between different tools. And most of the time, the build is sitting in a queue, or you’re burying yourself in log files digging for information about failures.
That is until now. Bitbucket Cloud is introducing Pipelines to let your team build, test, and deploy from Bitbucket. It is built right within Bitbucket, giving you end-to-end visibility from coding to deployment. With Bitbucket Pipelines there’s no CI server to setup, user management to configure, or repositories to synchronize. Just enable it in one click and you’re ready to go.
It’s all Bitbucket – Manage your entire development workflow within Bitbucket. No need for a separate tool.
Instant setup – You can create and run your CD pipeline once you sign up for Bitbucket. No agent configuration required.
Fast feedback – We show build statuses automatically everywhere you care about them – on branches, commits and pull requests.
Self-service for teams – Build configuration stored as code and out-of-the-box Docker support helps teams be independent.
Pipelines is also a great fit for branching workflows like git-flow. Anyone on your team can adapt the build configuration to map the structure of your branches. Here is a quick look at some of the salient features of Bitbucket Pipelines:
Bring your own services to Bitbucket Pipelines
We worked very closely with some of the leaders in the industry so you can bring your own services to Bitbucket Pipelines, right out of the box. Whether you want to deploy, test, monitor code quality, or store artifacts, complete any workflow with the tool of your choice: Amazon Web Services, Ansible, bitHound, BrowserStack, buddybuild, Code Climate, JFrog, Microsoft Azure, npm, SauceLabs, Sentry, Sonatype, and TestFairy.
“Pipelines provided us with the perfect opportunity to bring the power of automated code quality analysis to Bitbucket users. We’re excited about the awesome potential of Pipelines and they’re only just getting started!” –Michael Bernstein, VP of Community, Code Climate.
Continuous Delivery options from Atlassian
We believe that the best way to provide our customers with a top-notch cloud CD solution is to build the service natively within Bitbucket Cloud. That’s why we built Bitbucket Pipelines and also why today, we’re announcing the end-of-life for Bamboo Cloud, which will be discontinued starting Jan 31, 2017. While Bamboo Cloud has helped many customers to adopt CD, we realized that we would not be able to deliver the experience and the quality of service that our customers need. If you’re a Bamboo Cloud customer, click here to learn more about the migration options.
If you want to build and ship behind the firewall, we’re still heavily investing in Bamboo Server as an on-prem CD solution.
Get early access to Bitbucket Pipelines
With Bitbucket Pipelines we want to empower every team to accelerate their releases. No more time wasted on setup and maintenance, just focus on the work you love. You can sign up for the Bitbucket Pipelines beta program today and request early access.
Every few weeks, we set aside a week for what we like to call “Innovation Week”. During that time, our developers can work on whatever they like – feature enhancements, new features, bug fixes, performance improvements, etc. Today, we’re releasing one of the projects from our most recent Innovation Week: the ability to pin a comment in issues as an “Official response“:
Repository administrators can now pin their comment to the top of an issue’s comments section. It will be highlighted as an “Official response” right below the issue’s description and can be used for communicating a resolution status, highlighting open questions, or providing additional context and clarification. It will be particularly useful for large open-source repositories or repositories owned by organizations with large user bases.
This feature is available now for all users. Happy pinning!
Last year, we released a set of new webhooks to make integration with Bitbucket Cloud easier and more powerful. The response has been overwhelming. We recently added new troubleshooting tools to better support all of you developing integrations using Bitbucket webhooks.
Request details page
We’ve added a “View details” link next to each webhook request on the log table. The new “Request details” page includes a lot of useful information about the webhook request and response, including headers, bodies, and other specifics that will help you debug.
Resend request button
While developing or testing an integration, sometimes you need to trigger the same webhook multiple times while you make code changes between each request. This can be very time-consuming, slowing down your development speed. To alleviate this, we’ve included a “Resend request” button on the “Request details” page. Now you can just click once to resend the original request manually – no need to go through the steps to trigger the hook again. And if a request has been resent several times, each try will split into its own tab for easy reference.
Also, the request list view now displays an icon to indicate when a request has been attempted multiple times: