An update to our IP migration

By on August 6, 2018

We’re adding a third IPv4 subnet, 18.234.32.128/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 104.192.143.0/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.

Rerun your failed pipeline steps

By on July 31, 2018

Sometimes, your deployment 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.

step rerun pipelines

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 so that you can keep track of your build minutes.

step rerun pipeline example

For more information about rerunning failed steps, check out our documentation.

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

 

Do more from your inbox with Atlassian Cloud for Gmail

By 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, or even see who has or hasn’t approved a pull request. 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:

Get started today

It’s easy to get started – simply head over to the G Suite marketplace listing and install the add-on. We’re excited to to launch these productivity improvements and can’t wait to hear what you think!

 

Get the add-on today

 

13 new Bitbucket Cloud features

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

Chat integration:

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:

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.

Pull requests:

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

Pipelines:

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:


options:
  size: 2x  # all steps in this repo get 8GB memory
 
pipelines:
  default:
    - step:
        size: 2x  # or configure at step level
        script:
          - ...

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:


clone:
  lfs: true
 
pipelines:
  default:
    # ... 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:

Xcode integration:

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.

Code search:

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.

UI:

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.

Security:

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.

Bitbucket cloud security soc 2 type II

APIs:

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.

5 ways to make the most of Bitbucket and Jira Software

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

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

Creating a git branch from a Jira Software issue

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.

Using branch and merge permissions in Bitbucket

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.

Viewing contextual info in Bitbucket and Jira Software

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.

Viewing development info in Jira Software

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.

Release info in Jira Software

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.

New IP addresses for Bitbucket Cloud

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

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.

Firewall considerations

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:

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

SSH considerations

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 ‘18.205.93.1’

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.

Additional resources

Bitbucket Cloud Dev Week wrap up

By 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

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

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

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

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

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!

 

 

 

Instant notifications for your Bitbucket Pipelines builds

By on June 19, 2018

Earlier this year in April, we announced Bitbucket Cloud’s new and improved chatbot 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.

slack-config-pipelines

You can also customize your notifications experience to suit your team’s needs. For example, builds on your personal development branch can be sent to your private channel while builds on master or the main branch are sent to the broader team. This way, the team is notified only when it is relevant.

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 pipeline failed notifications are optimized for this scenario, letting you rerun your build from within your Slack channel.

pipelines-fail-notification

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.

pipelines-fix-notification

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.

pipelines-link-unfurl

Upgrade your chat notifications today

To connect your Bitbucket repository 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!

New Bitbucket Cloud V2 APIs

By 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 the API 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

Bitbucket Query Language (BBQL) is 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, and we use the additive partial responses operator to request that the reviewers are also returned in the response (by default they are omitted).

If you are familiar with GraphQL, you’ll find that the combination of BBQL and partial responses brings a lot of that 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 is built on top of the Open API Specification 2.0 (formerly Swagger), and as an Open API member organization, we built and released the RADAR doc generator tool for rendering documentation written according to this specification. Our updated documentation is designed to offer a more 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:

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

 

Bitbucket Cloud enhances enterprise cloud security with SOC 2 Type II report

By 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 your 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 leading Git repository solutions that can give you this assurance by successfully completing a SOC 2 Type II audit. What does this mean for you?

Bitbucket cloud security soc 2 type II

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 priorities 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 asking 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, you could embark on a 2 year journey of exchanging security questionnaires, negotiating with your security and compliance teams, and generally getting frustrated instead of just moving on with your real business. 

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 our cloud has the correct processes in place to stay up. Bitbucket is now the most trusted place to store your code and grow with you.

SOC 2 Type II unblocks the cloud 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.

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