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
By Alastair Wilkes on June 12, 2018
Imagine this scenario: your code’s ready to go, your teammates have approved your pull request, and the builds are green. Now you just need to merge your feature branch into master, but you have a choice to make: which merge strategy should I use?
Natively, Git offers several merge strategies. In Pull Request Merge Strategies: The Great Debate, fellow Atlassian Nicola Paoluicci presents the merge strategies that are most popular amongst teams, along with the pros and cons of each option.
As Nicola’s post mentioned, teams at Atlassian lean towards using explicit merge commits:
Bitbucket already supports squash on merge, which results containing your merged changes. The result? A tidy list of commits – one for each merge:
, squashed merges can be undesirable in some cases: you may want to maintain a linear commit history without squashing to a single commit. For example, if your feature includes an API change and a front-end change, you might prefer to keep those changes as separate commits – but you still want a linear history without merge commits.
Fast forward merge strategy
To use the new fast forward option the next time you merge, select it as your desired Merge strategy in the merge dialog:
Default merge strategy repository setting
As a matter of team policy, some teams would prefer to always use the same strategy. To make this easier, we’ve introduced a default merge strategy repository setting.
This setting determines which merge strategy should pre-populate by default when your team members merge a pull request in Bitbucket. From your repository Settings, you can find this option on the Merge strategies page under Workflow.
We hope you enjoy! If you have any feedback to share regarding this feature, tweet us @Bitbucket. Happy merging!
Try Bitbucket Cloud
By Claire Maynard on June 4, 2018
After the announcement of Microsoft’s acquisition of GitHub, Bitbucket started to see a spike in the number of GitHub users migrating their repositories to Bitbucket. Why? Many users understand they can get everything they had on GitHub in Bitbucket plus more, and at a lower cost. Tens of thousands of customers – including 60 of Fortune 100 – turn to Bitbucket as their code collaboration solution.
Start migrating from GitHub to Bitbucket
10 reasons why teams are moving from GitHub to Bitbucket Cloud
Teams can save 4x the cost moving from GitHub to Bitbucket. For example, if you are a team of 10 on GitHub, you have to pay $205 a month, while on Bitbucket you’re only paying $50. Bitbucket also offers free public and private repositories for teams with less than 5 users. GitHub doesn’t offer a free plan for users who want private repositories. On GitHub, even an individual developer has to pay $7 a month.
2. Superior integration with Jira
It’s been known for a long time that one of the best benefits of using Bitbucket is it’s best-in-class integration with Jira – the worlds number 1 agile software development tool for teams.
GitHub has an integration too, but check out all the things you can do with Bitbucket and Jira that you can’t do with GitHub:
- Create branches directly from Jira issues and start coding quickly. Nope, you can’t do that with GitHub.
- Interact with Jira issues without leaving Bitbucket. View, edit, comment or transition Jira issues inside Bitbucket’s UI. You can even add attachments to issues from Bitbucket. Nope, GitHub can’t do that either.
- Automatically connect commits, branches, and pull requests to Jira issues by adding the Jira issue key in the commit message. You can even require Jira issue keys in your commits so all of your work stays organized.
- Connecting Bitbucket and Jira only takes 30 seconds.
3. Built-in Continuous Integration and Delivery
On Bitbucket, you get a built in CI/CD solution that is unified with your source code. There are no CI servers to set up, user management to configure or repositories to synchronize. Just enable it within the UI and you’re done. What about with GitHub? Nope. GitHub doesn’t have a CI/CD solution. You have to go through the headache of finding, installing, configuring a new tool, setting up all your users over again, and you don’t benefit from the end-to-end visibility because all your CI information lives in a separate tool.
4. Bitbucket comes with Trello
This means the moment you set up a Bitbucket account, you get a Trello board – the fastest, easiest way to organize your projects, connect your work to code, and ship software, all for free.
5. SOC 2 Type II Compliance
With SOC 2 Type II compliance for both Jira Software and Bitbucket, the availability and security of your code is guaranteed. All the benefits of working in the cloud is now matched with an industry-first level of security, confidentiality, and availability for both your work and your code. Nah, GitHub is not SOC 2 Type II compliant.
6. Seamless integrations within the UI
Bitbucket Connect allows any developer to build deep integrations within the product UI in Bitbucket Cloud. You can stay within one tool to build and ship your software meaning no more context-switching between tools and tasks to get stuff done.
7. Code aware search
Semantic search that does the grunt work for you. Code aware search analyzes your code syntax, ensuring definitions matching your search term are prioritized over usages and variable names. With GitHub, you don’t get smart sorting and could spend hours finding what you need.
8. Mercurial Support
Bitbucket Cloud has Mercurial support. Mercurial is a free, distributed source control management system like Git. Have the freedom of choice and use the distributed version control system that works for you. GitHub? Nope.
9. Great for Open source projects too
Think GitHub is the answer for open source projects? Did you know Bitbucket also offers free public repos as well and hosts several large open source projects?
10. Using Slack?
With the Bitbucket bot for Slack, teams can take action from their channel – merge, comment, and even nudge reviewers on pull requests. With the Bitbucket Stride integration, you can “poke” people reviewing your PR as well. Nah, GitHub doesn’t have that either.
Are you self-hosting? Here are six reasons teams choose Bitbucket Server:
Our enterprise offering, Bitbucket Data Center, is 4x less expensive than GitHub Enterprise. For an engineering organization of 100 on GitHub Enterprise, you’ll pay $25,000 for a year. Bitbucket Data Center costs a fraction at $6000.
2. Native integration with Jira
It’s been known for a long time that one of the best benefits of using Bitbucket is it’s best-in-class integration with Jira – the worlds number 1 agile software development tool for teams. GitHub has an integration too, but check out all the things you can do with Bitbucket and Jira that you can’t do with GitHub:
- Create branches directly from a Jira issue and start coding quickly. Nope, you can’t do that with GitHub.
- Interact with Jira issues without leaving Bitbucket. View, create, comment or transition Jira issues inside Bitbucket’s UI. You can’t do that with GitHub either.
- Automatically connect commits, branches, and pull requests to Jira issues by adding the Jira issue key in the commit message. You can even require Jira issue keys in your commits so nothing get’s lost. Then, use Jira query language to find important development details – for example, search for all Jira issues with the status of “commit”.
- Best part of all, connecting Bitbucket and Jira only takes 30 seconds.
3. Bitbucket has better mirroring
GitHub Enterprise finally added mirroring Git repositories across different geographic locations, but can it keep up with Bitbucket Data Center? Select which projects are mirrored in a geographic location and Bitbucket will automatically sync and inherit user permissions. GitHub mirrors every repository, creating a bottleneck when pushing changes out.
4. Customizable pull request workflows
Bitbucket allows you to choose between five different merge strategies, create (and require) custom merge conditions, and configure default reviewers. GitHub expects you to use GitHub flow and be happy about it.
5. Superior extensibility
The Atlassian Marketplace houses over 200 Bitbucket Server compatible apps and more than 140 for Bitbucket Data Center. GitHub has 50. Not only do we offer more apps, but you also get access to the self-hosted Bitbucket’s source code. You’ll have to keep your GitHub representative on speed-dial for similar access.
6. Turnkey active-active clustering
We believe Git should scale with you. Easily add nodes to your Bitbucket Data Center cluster as your team grows. GitHub would rather you call them first before you can have an active-active cluster.
Start migrating from GitHub to Bitbucket
Move your team to Bitbucket Server
By Kelvin Yap on
Developer efficiency is always top mind for the Bitbucket team and we’re constantly looking at ways to get you up and coding as quickly as possible. For example, knowing so many of you use Sourcetree as your Git client of choice meant it was a no-brainer for us to add a ‘Clone in Sourcetree’ button as you browse through your repositories inside the product.
We’ve been looking at ways to expand this type of functionality and today we’re excited to announce support for 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.
And it’s easy to get the button working with the newly announced Xcode 10 – simply add your Bitbucket Cloud or Bitbucket Server credentials in Xcode and away you go:
Once set up, clicking on the “Clone in Xcode” button will launch Xcode and prompt you for a location on your local machine to clone the repository to.
Give the new integration a try and let us know what you think!
Try Bitbucket free
Using Bitbucket Server? This integration is available from 5.11 onwards. For those using versions 4.0 – 5.10, you can install it via Atlassian Marketplace.
By Jim Redmond on May 31, 2018
As part of our never-ending quest to secure your repositories, Bitbucket Cloud will be disabling support for TLSv1 and TLSv1.1 effective 1 December 2018.
This will affect all HTTPS traffic to Bitbucket, including:
- Git or Mercurial traffic to bitbucket.org
- The bitbucket.org Web interface
- API calls to api.bitbucket.org
- Hosted sites on bitbucket.io
- Any other HTTPS traffic not listed here
SSH traffic to bitbucket.org or altssh.bitbucket.org will not be affected by this change.
About 85% of HTTPS requests to Bitbucket use the newest version of TLS (v1.2). This includes all recent versions of our supported browsers, and most recent versions of Git and Mercurial clients. However, that other 15% includes a number of remote CI/CD systems (such as Bamboo or Jenkins), issue trackers (such as Jira Server instances), wikis (such as Confluence Server instances), and older versions of Git/Hg clients; all of those use older versions of Java, OpenSSL, or Python’s ssl module when negotiating the secured connection to Bitbucket, and all of those will be unable to connect to Bitbucket at all once we disable old versions of TLS.
Payment processing pages have already moved from TLSv1, to comply with PCI requirements.
How can I tell if I will be affected by this change?
We’ll be contacting some teams and users directly, based on what we find in our logs. If you’d like to be proactive, though, then be sure to check all of the things that you use to connect to Bitbucket, including (but not limited to) your browser, your Git or Mercurial client, your CI/CD system, any API clients, and anything else you may have linked to Bitbucket.
- SSH connections to Bitbucket are unaffected.
- Browser connections to Bitbucket are probably unaffected, unless you use a very old browser. Wikipedia has a chart detailing TLS support in Web browsers; you should be able to check your browser’s version there. Some browsers also make connection details visible in the developer tools, or by clicking the padlock icon in the address bar.
- Bamboo, Jenkins, Jira Server, Confluence Server, or any other Java-based systems that connect to Bitbucket may be affected; you will need to check the underlying version of Java. JDK 8 is unaffected; JDK 7 versions 1.7.0_131-b31 and later are unaffected; JDK 7 versions earlier than 1.7.0_131-b31 are affected; and JDK 6 and older are all affected. (Jira Cloud and Confluence Cloud are unaffected.)
- Graphical Git or Mercurial clients, such as Sourcetree, may be affected; please check with your vendor. (If you use Sourcetree for Windows 2.5.5 or later, or Sourcetree for Mac 2.7.2 or later, then the embedded Git and Mercurial clients are unaffected. If you use a system Git or Mercurial client with Sourcetree, then you might be affected; please make sure you’re on the latest client version available for your platform.)
- The Git command line on UNIX-based systems (including macOS, Linux, and all BSDs) may be affected. You should be able to test your connection from the command line:
GIT_CURL_VERBOSE=1 git ls-remote https://bitbucket.org/
This will connect to Bitbucket using the Git client and list the connection parameters. If you see a line like “SSL connection using TLSv1.2” in the output, then you are unaffected; if that line mentions a different version of TLS, then you are affected.
- The Mercurial command line on UNIX-based systems may be affected; please check your version of Python (with “python -V”). Versions 2.7.9 and later are unaffected, and most versions earlier than 2.7.9 are affected. Affected systems may also see some text in the command-line output – “warning: connecting to bitbucket.org using legacy security technology (TLS 1.0)” – though this will only show for newer versions of Mercurial. (Please note that PyPI and all other python.org sites will enforce TLSv1.2 after 30 June 2018, so you may not be able to upgrade individual Python libraries after that.)
- Finally, if you have an API client that queries Bitbucket, then please check the libraries your client uses to connect to api.bitbucket.org.
I’ve found an affected library or client, or you’ve contacted me to tell me that I will be affected by this change. What do I need to do?
Upgrade anything that is affected, before 1 December 2018. The exact details of your upgrade will depend on what you use, and how it’s installed; we don’t have enough room here to list all the different combinations, unfortunately, but we hope that the “will I be affected” section can point you in the right direction. (We’ll remind everyone as December approaches, but if your stuff is affected then you need to start planning this out now.)
We understand that system upgrades can be complicated, especially on shared systems, but keeping your repositories secure is a priority for us. We appreciate your support and patience as we disable old, insecure versions of TLS in six months’ time.
As always, please contact our support team if you need additional information.
By Matt Ryall on May 29, 2018
In the Bitbucket team, we believe containerization is the future of continuous integration and deployment. Running your software in containers brings consistency and predictability all the way from your development environment, through your CI/CD pipeline out to production.
To help smooth the path for container-based development, I wanted to reflect back on a set of improvements we’ve made to Docker support in Pipelines over the past few months, which bring speed and new capabilities to your build process. With these improvements, Bitbucket Pipelines is now the leading choice for building and shipping Docker-enabled applications in the cloud.
is Docker all the way
Docker applications will feel at home on Bitbucket Pipelines because everything in Pipelines is built on Docker:
- Your build environment is a Docker image. No pre-baked VMs with slow startup and six-month-old dependencies. As soon as a new release of your favorite platform hits Docker Hub, you can use it in Pipelines.
- The services your build uses (databases, etc) are just Docker images. They share a network interface with your build container, so you don’t even need to worry about port mapping.
- Built-in support for , tag and push. Just enable it in your build, and we’ll run a Docker-in-Docker daemon and provide the docker command-line tool so it works out of the box.
Here’s a showing how this all fits together:
But this is just the beginning with Pipelines. From this solid foundation, we’ve been able to layer on some great features that will make your Docker builds even faster and more powerful.
Lightning fast builds thanks to comprehensive Docker caching
“My build is too fast”, said no developer, ever. We’ve built several levels of caching into Pipelines for Docker users, so your Docker builds can run as fast in the as they do locally:
- Image caching will automatically apply to all public Docker Hub images used in your build.
- Layer caching will include all images and intermediate layers used by the Docker-in-Docker daemon that powers your Docker builds on Pipelines. Enable this by adding the docker cache to your Pipelines steps, as shown below.
- Custom caches can be defined in your Pipelines configuration, allowing you to cache the things that we miss. (These are flexible enough that we actually implemented layer caching in this way.)
Among customers who have enabled Docker layer caching, we’ve seen 80% of repositories shave off more than 30% of their uncached build time – and almost half (49%) have cut more than 50% off their uncached build time. These dramatic reductions will save real time in your team’s daily feedback loop.
Docker builds up to 7GB with configurable memory limits
With two improvements that enable bigger and more complex builds, you can now use up to 7GB for building and running Docker containers in Pipelines:
- Large builds support allows you to allocate a total of 8GB of memory to your build (up from 4GB). Double memory costs you double the build minutes, so we recommend using it only where you need it.
- Configurable memory for services allows you to specify how you want to this memory allocated. We require 1 GB for your build image and our overheads, so the 7GB remainder can be allocated to service containers or to your own Docker containers.
Here’s an example of configuring 7GB for Docker operations in bitbucket-pipelines.yml:
size: 2x # double memory (8GB) for this step
- ... # do some memory-intensive docker stuff
This additional memory might make you wonder why you wouldn’t just spin up your entire application in Pipelines for some delicious integration testing. Which leads us on to…
Spin up your entire application with
If you’re using Docker heavily, you probably have a bunch of docker-compose YAML files to kick off your application in a variety of configurations. With the Docker-in-Docker daemon in Pipelines, you can now use docker-compospin up your entire application for testing.
Below is an example of using docker-compose with a 7GB memory allocation to spin up a set of services and test them out.
Note that this example has a few extra commands to install the mysql client and docker-compose binaries that aren’t necessary in a real build scenario, where you would bake your dependencies into a custom Docker image for your build environment.
size: 2x # double memory (8GB) for this step
- apt-get update -y && apt-get install -y mysql-client
- curl -L https://github.com/docker/compose/releases/download/1.19.0/docker-compose-Linux-x86_64 -o /usr/local/bin/docker-compose
- chmod +x /usr/local/bin/docker-compose
- docker-compose up -d
- docker-compose ps
- ./wait-for-container.sh build_mysql_1
- echo 'select 1' |
mysql -h 127.0.0.1 -u root -psecret testdb
- docker-compose logs mysql
This example uses this docker-compose.yml, and wait-for-container.sh – a small shell script to poll the Docker health check and wait for a container to start.
If you want a better look at how this docker-compose example fits together, check out the docker branch in my demo repository.
Try Bitbucket for your next Docker-powered project
If your team is big into Docker, you now have a list of great reasons to try out Bitbucket for your next project.
Try Bitbucket today, and enjoy the benefits of a CI/CD solution purpose-built for Docker.
Try Bitbucket free
By Aneita Yang on May 15, 2018
Last month, we announced the general availability of Bitbucket Deployments, a new feature within Bitbucket to help you keep track of the status of your shared deployment environments. With Deployments in Bitbucket, your team has every capability they need, from code hosting, code review, built-in CI/CD and now deployment tracking, to build and ship great products from within Bitbucket.
But there’s still a lot of uncovered potential for Deployments. Imagine, for example, that you push some code which triggers a pipeline that deploys to production. Halfway through, your colleague pushes more changes that also trigger a deployment – two deployments are now running!
. This gives teams confidence about the status of their environment and eliminates any uncertainty about whether deployments are running in the right order. We’ve listened to your feedback and realise how important it is for Bitbucket to just do the right thing.
we’re excited to announce that Bitbucket Deployments is the first CI/CD to automatically enforce Simply by adding deployment tracking to your pipeline, we will automatically ensure that only one deployment is in
“This is amazing! There’s nothing more frustrating than a 35min build failing because the environment is still updating”
– Ken Greeff, Software Engineer at Realhub Systems
How does the concurrency control work?
Deployment concurrency control requires you to first enable Bitbucket Deployments for your repository. With deployment tracking enabled, Pipelines will then check whether there is already a deployment in progress before starting a new one to the same environment. If there is already a deployment in progress, later deployment steps will be paused. You can manually d.
– by letting the in-progress deployment to finish executing before allowing a later deployment to be run, the status of your environment will always be known and your deployment won’t fail due to unavailable resources. Keep in mind that Bitbucket Deployments tracks the status of shared environments in the repository, and that developer’s individual test environments don’t need to be tracked.
We’re super excited to share this addition to Bitbucket with you. If you have any feedback to share, tweet us @Bitbucket. Happy deploying!
By mjopson on May 10, 2018
code aware search: a semantic search that ranks results by relevance, starting with the function or type definition first. It was built this way to save time manually combing through results when looking for things like classes, interfaces, structs or enums. We’ve continued to expand it by adding a code search API so developers can make code search work for their unique needs.
Since launch, code collaborators could efficiently find the code they were searching for, but results for a file search would show usages of the filename in the code and not the actual filename. This caused a lot of effort to find the file. To fix this, we’ve launched improved file search support which now includes filename matches, extending the syntax-aware code search.
What’s new with file searches?
#1 Search results take into account filenames and paths
Files can now be found just by searching their filename or parts of the path.
If a search matches both in a file’s path and content, those results are shown first. We aim to match the developer’s search intent with smart ranking by boosting search results based on matches in the file’s name, path or code.
#2 A path modifier to refine results
A developer searching for a common phrase or name would get served overwhelming results that they would have to click through page after page to find the right result. To make this easier, a developer can now enter the path modifier, which can be used to limit the search to certain paths or exclude them.
A lot of people will have checked in node_modules and so it’s a very common match. The new path modifier supports a NOT option so the search could be updated to path:package.json -path:node_modules lodash to exclude those matches.
Bonus: A similar filter can be achieved using path anchoring, searching with path:/package.json lodash will only return results for package.json files at the root of the repository.
Try Bitbucket Cloud’s file search
If you’re ready to give our robust and relevant search a try, sign up for a Bitbucket Cloud account, create a repository, and .
If you’re already a Bitbucket customer, you can find code search with improved file search from your sidebar read further documentation on it here.