By Jim Redmond on August 6, 2018
We’re adding a third IPv4 subnet, 220.127.116.11/25, to our lists of inbound IP addresses. This new subnet will work along with the two IPv4 subnets we announced in an earlier blog post.
This new subnet should resolve some ongoing networking issues reported by some of our users in Russia. As before, most users will not have to do anything here. However, you may need to update your firewalls to include the new range.
As a reminder, all of the new subnets (the new one listed here, the two IPv4 subnets we’d previously announced, and the IPv6 subnet we’d previously announced) include bitbucket.org, api.bitbucket.org, altssh.bitbucket.org, and all bitbucket.io hostnames.
Webhooks and Pipelines source IPs are still not changing.
Finally, we will be decommissioning our prior IP addresses (from 18.104.22.168/24 and 2401:1d80:1010::/64) in the coming weeks. If you have added one of those addresses to a hosts file (such as /etc/hosts) or to a local DNS resolver, then please update or remove that entry as appropriate.
As always, please contact our support team if you have further questions or if you need further assistance.
By Aneita Yang on July 31, 2018
Sometimes, your pipeline can fail due to external factors – for example, from a misconfiguration in your deployment tool or an incorrectly set environment variable. This is a common problem to run into and an easy problem to fix.
But after fixing the misconfiguration, you need to rerun the entire pipeline in order to execute the failed deployment step. This means a complete rebuild of artifacts and going through the testing phase again. We’ve received feedback from teams that this is both time-consuming and a waste of resources.
Today, we’re excited to announce that you can now rerun only the failed steps in your pipeline. You can get the feedback that you need from your pipeline much sooner, without having to rerun steps that were already successful.
Through the web interface, you will also be able to see who reran the failed steps and how many times a step has been rerun your build minutes.
For more information about rerunning failed steps, .
We hope you enjoy this addition to Pipelines! If you haven’t tried Pipelines, get started today and improve the way your development team works.
Try Bitbucket Pipelines
By Kelvin Yap on July 30, 2018
As part of the Atlassian Cloud for Gmail add-on announced at Google Next, we’re proud to unveil the numerous features the add-on allows for Bitbucket Cloud users inside Gmail, making it easy to take action and get contextual information on your pull requests, issues, and pipelines builds without leaving your inbox.
Get context on work
For emails that contain certain types of URLs from Bitbucket, the Atlassian app surfaces contextual information related to your work inside Gmail. You can read all the comments on a Bitbucket issue, view information about a pull request or pipelines build, . The Atlassian app also integrates with Jira, allowing those that use both Jira and Bitbucket Cloud to get a full picture of the status of their work on the go.
Take action inside Gmail
Best of all, you can take action on the notifications you receive via email, meaning more efficiency in your day to day workflow and less switching between apps to get stuff done. The Atlassian Cloud for Gmail add-on allows you to perform the following actions in Bitbucket Cloud from your inbox:
- Comment directly on an issue
- Comment on a pull request
- Merge a pull request
- Re-run a pipeline build
Get started today
It’s easy to get started – . We’re excited to to launch these productivity improvements and can’t wait to hear what you think!
Get the add-on today
By Justine Davis on July 19, 2018
We’ve been busy shipping some features you’ve been asking for. With so much going out, we wanted to do a quick round up of all the things so you can pick and choose which ones you need. Let’s get right to it.
1- New chatbot – Bitbucket’s new chatbot is now available for Slack. To help with focus and stop being inundated with notifications, Bitbucket performs an automated analysis of your repo and configures notifications tailored to your usage patterns. By default, we inform you about:
- pull request activity and commit comments across the entire repo
- pushes, merges, and build notifications from your primary branch (typically master or default)
- Detects if you are using a Gitflow branching strategy and will notify your team when a branch is created
In addition to the default options, you can respond to notifications in-app by doing things like creating a pull request, re-running a failed build, or replying to a pull request comment.
2- Fast-forward merges – Natively, Git offers several merge strategies: merge commits, squash on merge, or fast forward merge strategy. Bitbucket supported merge commits and squash on merge and has now added a fast-forward merge. A fast forward merge will apply your source branch commits to the destination branch by moving the HEAD of the destination branch to the HEAD of your source branch (if there are no other commits on the destination).
3- Large builds in Bitbucket Pipelines – teams that need additional memory or speed in Bitbucket Pipelines can now run large builds by configuring the size of their pipeline to 2x. This helps teams that need to build large scale or legacy applications with larger resource requirements, perform in-memory analysis of large datasets, use parallel testing, or run more service containers. To add this for a build:
size: 2x # all steps in this repo get 8GB memory
size: 2x # or configure at step level
4- Git LFS in Bitbucket Pipelines – Clones with projects containing large files, can take forever because every version of every file has to downloaded by the client. Git LFS reduces the impact of large files in your repo by downloading them during the checkout process rather than during cloning and Bitbucket Pipelines now has built-in Git LFS support. To use it, add this to the clone section of your bitbucket-pipelines.yml:
# ... rest of Pipelines configuration ...
5- Build parallel steps – In order to get feedback faster, you often need to run groups of tests at the same time to cut build time so we added parallel steps. See it in action:
6- Bitbucket Deployments now Generally Available – keeping up-to-date with what has been deployed has increasingly become more difficult for teams, but it doesn’t have to be. We made Bitbucket Deployments generally available to make it easier to track deployments, preview and promote deployments between environments, and view deployment history.
7- Automatic concurrency control – You aren’t the only person pushing code on your team that kicks off a deployment. We launched automatic deployment concurrency control so if 2 team members deploy at the same time, you have the confidence that deployments are happening in the right order, one per environment at a time. This alleviates worries about what your production environment will look like when there are multiple deployments at the same time.
8- Docker based software – Is your application using Docker? Since Pipelines is built on Docker, we’ve invested heavily in Docker improvements to make sure applications using Docker feel at home. We’ve added:
- Docker caching so your builds can run just as fast in the Cloud as they do locally
- More memory so those building and running Docker containers in Pipelines can now use 7GB
- Docker-in-Docker daemon so you can use docker-compose to spin up your application for testing
9- Xcode – We launched support for cloning a repository in Xcode. It’s simpler than ever to open the code found in Bitbucket Cloud or Bitbucket Server in Xcode – as long as your repository contains a .xcodeproj or .xcworkspace file a new ‘Clone in Xcode’ button will now appear.
10- Code search API and file search improvements – We’ve continued to expand our code aware search by adding a code search API so you can make code search work for your unique needs. For those searching for files, we’ve improved the ranking to be more in line with our semantic search that ranks results by relevance. Our improved file search support now includes filename matches instead of usages of the filename.
11- new source browser – We prioritized clarity and simplicity of viewing source code in the new source browser. We combined the repository overview and source tabs, added a new right sidebar, updated the directory listing, and made it a more responsive single page app for faster transitions.
12- SOC 2 Type II compliance – We put in a mountain of effort to ensure the security, privacy, and availability of your code, and are proud to be the first of the leading Git solutions to successfully complete a SOC 2 Type II audit.
13- Bitbucket Cloud’s V2 API – Our V2 API for creating apps for Bitbucket Cloud got a facelift. Looking for all the APIs for Bitbucket? Look no further.
Ready to take these features for a spin?
If you’re new to Bitbucket, sign up for a Bitbucket Cloud account. Already a Bitbucket customer? Check out the individual blogs for instructions on enabling your desired feature.
Get started, it’s free
Have more specific questions about this post? Reach out to us on Twitter to get the information you need.
By Kelvin Yap on
In a recent study of software development teams using Jira Software, we found those that integrate with Bitbucket release 14% faster than those that don’t. For many industries where the pace of change is rapid and the market incredibly competitive, it’s this speed that can separate the great products in the eyes of users from the merely “good” ones.
how do these teams release their products faster using Jira Software and Bitbucket Cloud, all the while maintaining visibility across the team and ensuring each release is of high quality? Here are five tricks they’ve got up their sleeves.
1: Let the tools keep your team up to date
We all understand the importance of keeping the rest of the team up to date on progress on work for a release but let’s face it: this can be quite the chore when all you want to do is focus on getting your work done. So how do teams that release so often keep everyone up to date without sacrificing release velocity? Simple. They take advantage of the integration between Jira Software and Bitbucket and let the products do the updating for them.
By creating a branch directly from the issue in Jira Software or adding the issue key to any commit, branch, or pull request in Bitbucket, a link is created between your code and the issue you’re working on. This link means your team is kept up to date in real time in Jira automatically as you work and, in conjunction with workflow triggers, actions like creating or approving a pull request automatically change the status of the Jira issue too.
Smart commits are another great way you can update your team as you work, allowing you to comment on, log time against, and even transition an issue using your commit messages.
2: Create the perfect workflow for your team
How often teams release depends on how robust their development workflow is and how disciplined the team is in following it. Utilizing Jira Software’s ability to customize workflows it’s possible to map the ideal workflow for your team, ensuring best practice and minimizing any unexpected circumstances that can delay a release. And paired with required checks before a merge in Bitbucket, it’s easy to implement a process that ensures quality and makes sure code is reviewed, merged, and built appropriately before being deployed to your users.
3: Make it easy to understand the context
For a developer on your team trying to get context on their work the process of switching between tools can be slow and laborious. The workflow triggers can help keep your team up to date, but what can be done to help an individual stay on top of what needs to be done?
For teams that integrate Jira Software with Bitbucket, it’s easier than ever for a developer to see or ask for contextual information from their team in Jira inside Bitbucket.
The integration allows users to not only view a Jira issue inside Bitbucket’s interface but interact with it, too. Adding comments, viewing attachments, or making edits to the issue itself – all this and more is available without having to leave the product.
4: Build confidence in your releases
Confidence plays an integral part leading up to any release. Has all the work been completed? Has the code been properly reviewed and tested? Release readiness is important to ensure the quality of your product, so how do teams that utilize Jira Software and Bitbucket together maintain quality but still release at a faster velocity?
The benefit of the integration really comes to the fore for teams who link their code with an issue, as it’s easy to get real-time updates via the development panel. No more adding comments to an issue requesting an update or pinging the team in Stride, each issue shows everything you need at a glance to better understand how close your next release is to being ready.
5: Get a bird’s eye view with the release hub
Best of all, all the issues related to a release can be seen in the release hub. The release hub offers an automated, bird’s eye view of how ready your next release is, rolling up all the information the team needs to decide when to deploy to customers.
It all starts with the integration
With the right tools at your disposal releasing often without sacrificing quality isn’t rocket science. With the tips above alongside many other integrations for your team to take advantage of, integrating Jira Software with Bitbucket will increase the velocity of your releases in no time. But don’t take out word for it, integrate them today and try out yourself!
Learn more here.
By Jim Redmond on July 2, 2018
What are we doing?
We’ll start a gradual rollout of changing our A records in DNS starting at 22:00 UTC on Sunday, July 29 2018 to point to new IP addresses. The rollout is expected to be completed for all our customers two weeks later, i.e by the 15th of August.
There will not be any downtime for this migration, and most people will not have to do anything differently because of this migration.
Why are we doing this?
Bitbucket has seen amazing growth over recent years, with millions of users working in Bitbucket to build better software. As part of that, we are planning a Cloud migration which will allow us to:
- Take advantage of more auto-scaling capabilities in the Cloud
- Easily add/remove network services capacity
- Co-locate with our Atlassian PaaS platform that supports Jira, Confluence, StatusPage, and other Atlassian products
- Scale Bitbucket’s infrastructure to meet future demand
- Our new Cloud IP address space, along with some underlying network improvements, would make response times noticeably faster for some users, depending on location
- Just as important, these changes make it easier for us to improve upstream network connectivity and load balancing
How will this affect you?
Most users will not have to do anything special for this migration. Your DNS servers should pick up the new IPs within a few minutes of the migration, and your systems should start using the new IPs right away. We’ll keep the old IPs running for a few weeks afterwards just in case, though.
If you control inbound or outbound access with a firewall, then you may need to update your configuration. Please whitelist these new IPs now; you should be able to remove the old IPs after the migration is complete.
New destination IP addresses for bitbucket.org, bitbucket.com, api.bitbucket.org, bitbucket.io, bytebucket.org, altssh.bitbucket.org will be:
- IPv4: 22.214.171.124/25, 126.96.36.199/25, and 188.8.131.52/25
- IPv6: 2406:da00:ff00::0/96*
Note: this IPv6 range includes subnets that are not necessary owned by Atlassian, but is the longest subnet that matches *all* Bitbucket IPv6 Atlassian IPs. We will post a list of the exact IPv6 addresses at https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html soon.
Webhooks IPs will remain unchanged as per https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html
Our server’s SSH key is not changing, so most SSH clients will continue to work without interruption. However, a small number of users may see a warning similar to this when they push or pull over SSH:
Warning: the RSA host key for ‘bitbucket.org’ differs from the key for the IP address ‘184.108.40.206’
The warning message will also tell you which lines in your ~/.ssh/known_hosts need to change. Open that file in your favorite editor, remove or comment out those lines, then retry your push or pull.
By Kelvin Yap on June 28, 2018
As part of the update to Bitbucket Cloud’s V2 APIs we announced a couple of weeks ago, we invited five companies from our developer ecosystem to build apps during Dev Week, a week long event at our offices in San Francisco. The premise of the week was simple – with a focus on providing a more robust and consistent usage experience when building integrations with Bitbucket Cloud, what better way to put the updated APIs to the test than putting them in the hands of app developers themselves? A number of Bitbucket Cloud developers teamed up with these partners, helping them build their integrations on the Connect platform and helping identify other ways we can improve the APIs and the overall developer experience.
We received great feedback throughout Dev Week, with everyone impressed with the new APIs and with Connect in particular, which allowed them to build their apps at speed and with ease.
“Our product integrates with a lot of tools in a developer’s toolchain, and integrating with Bitbucket Cloud was by far the easiest so far.” – Sourcegraph
Each of the five partners plan to release their apps shortly, and we’ll be highlighting each one with blogs over the coming months. Here’s a brief look at the apps coming to Bitbucket Cloud in the not-too-distant future.
Fossa provides tools that continuously scan and comply with open source licenses without slowing down development. For Dev Week, they built a “Dependency Insights” dashboard for Bitbucket Cloud, allowing users to view an index of all the third party code their team depends on and receive alerts about any issues at-a-glance.
JFrog builds tools that handle artifact management and distribution, including Artifactory and Bintray. They focused on building a release management dashboard in Bitbucket Cloud that shows artifacts created during a release cycle that works with both Bitbucket Pipelines and Bamboo. They also built a second integration with Bitbucket Pipelines to push packages to Artifactory using the JFrog CLI.
pullRequest is an integrated marketplace for code review, allowing teams to get their code reviewed through pullRequest’s network of third party developers. The team built a real time review app that syncs code review work being performed by third party reviewers in pullRequest with the Bitbucket Cloud pull request.
SonarSource provides world-class solutions for continuous code quality. The application they built during Dev Week targets teams who analyze their source code on SonarCloud and who want to display code quality results inside Bitbucket Cloud, from the repository overview page, inside pull requests, or triggered via Bitbucket Pipelines.
Sourcegraph is a tool that helps code search and intelligence. The team built additional search and forward navigation into Bitbucket Cloud, including hover tool tips that allows users to jump to the definition or all the references to a function or class in Sourcegraph.
A big thanks to all the partners who attended the week and helped put our updated APIs and docs to the test. And if you haven’t tried them out yourself, give them a go and let us know what you think!
By Aneita Yang on June 19, 2018
Earlier this year in April, we announced Bitbucket Cloud’s new and improved and the range of notifications that can be sent to your Slack channel. Amongst the improvements are notifications for Bitbucket Pipelines. You can now choose the notifications you’d like to receive on a per-channel and per-branch basis to keep the right people on the team notified when a pipeline succeeds, fails or is fixed.
Per-channel and branch notifications
Receiving notifications for every build in the team’s main channel can become quite noisy. This is why the default behavior for a new chat subscription is to only send pipeline failed and pipeline fixed notifications for builds on the repository’s main branch.
You can also
Rerun your build from your channel
Sometimes, builds can fail because of external factors – for example, an external deployment tool may have insufficient resources – and simply rerunning the pipeline will allow it to execute successfully. Our notifications are optimized for this scenario, letting you rerun your build from within your Slack channel.
Updates when your pipeline is fixed
Notifications for successful builds can generate a lot of noise in a channel but there are times when it’s important to know when the pipeline has succeeded. We’ve introduced pipeline fixed notifications for this reason, giving your team confidence that bugs have been resolved and the pipeline has returned to a successful state after a previous failure.
Pipeline information without leaving Slack
Alongside pipeline status notifications, Bitbucket can also provide you with contextual information about your pipeline. If you reference a link to a pipeline in your channel, Bitbucket will show you all of the relevant information about the pipeline – its status, duration, branch and commit hash. This helps provide the team with context about the build without needing to leave Slack.
Upgrade your chat notifications today
To connect your Bitbucket repository to Slack:
- Navigate to your Bitbucket repository
- Click on Settings in the lefthand navigation
- Select Settings under Chat Notifications
- Follow the prompts to Connect to Slack
If you’re using the legacy Slack integration, make sure you uninstall it to avoid receiving multiple notifications for your builds.
This integration will be coming soon to Stride, so stay tuned for updates. We hope you enjoy the upgraded notifications experience!
By Ian Dick on June 15, 2018
Today Bitbucket Cloud is proud to announce an update to its V2 API, designed to offer developers a more robust and consistent usage experience when building Bitbucket Cloud integrations. And while we’ve improved and its documentation to make for a smoother integration experience, we’re most excited for you to try the changes we’ve made to Bitbucket Connect and the API Proxy. It’s now easier than ever to build efficient and performant apps for Bitbucket Cloud.
Build with greater coverage, consistency, and control
We heard from many of you that consistency was lacking with version 1.0 of Bitbucket Cloud’s API, and we’ve set about focusing on a more consistent experience with this update. And with more exciting changes to come, you can expect more thoughtful design and uniformity moving forward.
With that in mind, here are the biggest changes to Bitbucket Cloud’s V2 API.
Filtering results with BBQL and partial responses
s a generic querying language you can use to filter results from Bitbucket. With BBQL you can configure your Bitbucket integrations to only request and handle the data that matters to them. Different but related is the ability to query for partial responses, since this lets you be explicit about what fields you do or don’t want included in the response. These methods for filtering the response data aren’t just useful for trimming down the data returned to your application, they actually improve the time taken to process the request in Bitbucket thanks to lazy evaluation of the data being returned.
See it in action
In the following example we’re querying for issues with a title like “timeouts” and where the issue priority is at least “major”, and we’re asking for exactly the title, state and assignee username to be returned in the response. The q query parameter indicates some BBQL that we want to include, and the fields query parameter indicates that we want to use partial responses to choose what fields are returned.
In the next example, we use BBQL to query for pull requests that were created after the 1st of February 2018,
If you are familiar with GraphQL, you’ll find that the combination of BBQL and partial responses brings power and flexibility to plain REST endpoints.
Better dev docs, for the win
Good APIs are nothing without good documentation, so we spent time addressing the gaps and inconsistencies we found in our developer documentation with this update. Our new API documentation thorough and understandable overview of what endpoints are available and how they work.
Like everything we build at Atlassian, we depend on feedback from our integrations partners. So peruse through our doc and give us some feedback in the Atlassian Developer Community. Tell us, what’s working? What’s missing? Where can we do better?
New APIs recently released
We recently rolled out some new additions to the V2 API to help you write amazing integrations. Check out the fancy new documentation for:
Bitbucket Connect and the API proxy, a game-changer
Last but certainly not least, we have Bitbucket Connect. For those unaware, a great way to develop integrations for Bitbucket Cloud is to use the Atlassian Connect framework. Integrations built using Atlassian Connect can do things like query the Bitbucket Cloud APIs on behalf of users, and also add content to the UI to customize the look and feel of apps built for Bitbucket.
Another great benefit of apps built with Connect is the ability for apps to add their own endpoints to the Bitbucket Cloud API. Requests to such resources are proxied via Bitbucket Cloud and then sent on to the application for handling. Doing this comes with a host of benefits, including:
- a feel that the application is part of Bitbucket Cloud
- objects can be hydrated by the API proxy on the way to the application, which greatly reduces the need for applications to replicate data from Bitbucket Cloud in their own data stores, and this is important for applications that are trying to reduce the amount of sensitive data they are storing about users in a post-GDPR world
- user authentication is handled by Bitbucket Cloud, which allows for simpler logic in the application
- transparent permission checks can be used to apply authorization at the proxy before requests are forwarded to the application
This is our most exciting change with our new API improvements. Why? Because the proxy module aims to provide a much tighter and simpler integration experience for applications. We’re excited to see what you build with it, and encourage you to leave some feedback in the Atlassian Developer Community to tell us how you’re using it, and how it can be improved in future iterations.
V1 is now deprecated – As of today the V1 API is deprecated and we encourage all third-party developers to migrate over to our shiny new V2 APIs.
Try Bitbucket free
By Justine Davis on June 13, 2018
The most important things to look at when deciding where to host your code with a cloud provider are cloud security, confidentiality, and availability. Without those important components, features, price, and integrations simply don’t matter if you don’t know code is secure.
How do you know the company hosting your code is properly guarding it, and giving the right people access to your repos only with your permission? How can you be sure they don’t accidentally delete something? Bitbucket Cloud is the first of the solutions that can give you this assurance by successfully completing a SOC 2 Type II audit. What does this mean for you?
Confidence in code security, confidentiality, and availability
Whether you’re already a medium to large sized company or quickly becoming one, security and availability are your top when managing your organization’s code within a DVCS. If (and when) your compliance team steps in and asks for assurance that your Git provider’s security and availability are in line in the cloud, what do you do? If your customers are you for SOC 2 Type II, what do you do?
With Bitbucket, you hand over our SOC 2 Type II certification and go on with your day. With other Git providers,
By having Ernst & Young complete this audit, we’ve assured that we have the checks in place so we won’t expose your code, we won’t lose your code, and . Bitbucket is now the most trusted place to store your code and grow with you.
SOC 2 Type II unblocks the c for on-premise teams
On-premise teams have wanted to use the cloud for its flexibility to scale, decreased hardware costs, automatic software updates and the ability to access information anytime but have felt blocked by concerns over cloud security. Having your full software development workflow in the cloud from apps to your CD pipeline can and will accelerate business velocity.
Now, with SOC 2 Type II, teams are able to make that move from server to cloud with assurance that their code is safe and reap the benefits of the cloud.
Enterprise-grade cloud security controls
In addition to SOC 2 Type II compliance, Bitbucket Cloud offers enterprise-grade security controls to further ensure your code is secure.
- Account admins can require their team to have 2 step verification to access private code
- IP whitelisting blocks a user from interacting (view, push, clone) with your account’s private content unless they’re accessing it from an IP address you’ve selected.
- You can set merge checks to control when a pull request can be merged like requiring a minimum number of approvals, requiring tasks to be resolved, enforcing a minimum number of successful builds, and more.
- SAML single sign-on allows you to connect Bitbucket directly to your identity provider (we support Azure AD, Okta, Onelogin, Centrify, and Bitium) so you can add new starters or remove access for employees leaving your company. (Available via Atlassian Access)
Required 2 step verification, IP whitelisting and merge checks are available under Bitbucket’s Premium Plan for $5/user/month.
Step up your security
If you’re ready to enhance your security measures, sign up for a Bitbucket Cloud account.
Try Bitbucket free