Bitbuckethttps://blog.bitbucket.org
The Git solution for professional teams. Collaborate on code in the cloud or on your servers.Wed, 13 Sep 2017 17:14:48 +0000en-UShourly1https://wordpress.org/?v=4.8.2https://blog.bitbucket.org/wp-content/blogs.dir/10/files/2017/09/cropped-android-chrome-512-32x32.pngBitbuckethttps://blog.bitbucket.org
3232Say Trello to boards in Bitbucket Cloudhttps://blog.bitbucket.org/2017/09/13/say-trello-to-boards-in-bitbucket/
Wed, 13 Sep 2017 15:28:11 +0000https://blog.bitbucket.org/?p=3446Your team just came up with a great new idea for a feature, product, Airbnb for dogs, whatever it is….it’s amazing (naturally) and you’re ready to get started. But often building a product feels like chaos with so many spreadsheets, emails, chats, bugs, features, releases, and more. Keeping track of it all seems impossible. Wouldn’t it be nice if you had one place where your whole team could plan requirements, assign tasks, start coding, collaborate, and deploy to your customers? If you didn’t have to fumble around deciding where you’re going to document user stories and requirement details? And what if you could bring your designers and marketers into the conversation instead of having to collaborate with them through a separate medium? Well, now you can! With Trello boards in Bitbucket Cloud, spin up a Trello board and get your entire team on the same page, instantly. If you haven’t heard of Trello, well, get ready to get work done, fast. Trello’s boards, lists, and cards let you organize and prioritize projects in a fast, flexible way. Trello is one of the worlds most popular project planning and collaboration tools, and it’s now a core part of Bitbucket’s experience. Already, 14% of Bitbucket customers use Trello for planning their software projects, and we’ve made it even easier for teams to plan and track in the tool they already know and love. Give your team a shared workspace that takes you from planning to deploying with hackathon speed – for free. Why use Trello boards in Bitbucket? Everything in one place With boards in Bitbucket, you now have one place for planning, tracking, collaborating on code, testing and deploying. Developers save time by never bouncing between multiple applications and losing context to find their next piece of work. You don’t have to add and configure user permissions in a separate tool because access to Trello boards can be set based on Bitbucket’s repository permissions. Keep work moving fast by having everything and everyone organized in one tool. Simplify your workflow – create branches directly from cards Plan projects on a Trello board and get to coding quickly by creating a branch straight from a Trello card. Create a pull request in Bitbucket and attach it to a card to keep everyone in the loop on the status. Pick your next card from a prioritized backlog on the board and move cards through your workflow to ensure all work is complete. Get project status at a glance Quickly understand the status of the team’s work in a simple, digestible view without navigating around Bitbucket to find related work. Gain total traceability with branches, commits, and pull requests all associated with cards on the board. Even see build and pull request status from the front of the card with color-coded card badges that help you recognize if there are any issues. Daily stand-ups are a breeze with information like status updates, code reviewers, and more all within the details of the card. Collaborate with your team – no coding skills necessary! PMs, engineers, designers, and marketers and many more contribute to the success of your product team. Extended teams now have a common language and workspace to collaborate on projects without needing to understand Bitbucket. Everyone can have one view of all their work without switching between multiple applications. Product teams can prioritize tasks and get perspective on the work getting done, and non-technical teams, like marketing, can see what’s shipping and share it with customers. “The Trello integration with Bitbucket makes it easy for our developers to collaborate with our marketing team who want a fast and simple tool. They have access to our development backlog and can quickly add things like bugs, feature requests, or changes to the website.” – Alex Brown, Sr. Web Developer from Lushusa.com We launched Bitbucket’s Trello Power-Up back in March. If you haven’t already, make sure to install it to take advantage of the full integration. Using Bitbucket? Here’s how to get started Trello boards are now available on all repositories in Bitbucket. Just navigate to a repo, click on the board menu item in the sidebar, and get started. If you already have a Trello account, you can select an existing board from the drop down or create a new board. If you want to have more than one board, go to the repository settings and attach a second or third board. Need some inspiration? Use a Trello board for agile development, bug tracking, a product roadmap, sprint retrospectives and more. Check out some of Trello’s engineering use cases. Using GitHub? This is a great reason to try Bitbucket. We have Trello integrated – obviously! Marketers and Designers don’t want to learn how to use GitHub issues. Bitbucket has integrated CI/CD with Pipelines, so developers don’t spend time doing maintenance on Jenkins servers and GitHub integrations. With built-in Pipelines, see the status of your builds right in your repo. Take your code from testing to deploying in seconds. Bitbucket offers free unlimited private repositories. Nice! And, best of all, get all of this for around 25% of the cost of GitHub. Try it all for free (even premium features) for 30 days. No credit card required. Import your repo here. Get started, it’s free Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

]]>Your team just came up with a great new idea for a feature, product, Airbnb for dogs, whatever it is….it’s amazing (naturally) and you’re ready to get started. But often building a product feels like chaos with so many spreadsheets, emails, chats, bugs, features, releases, and more. Keeping track of it all seems impossible.Wouldn’t it be nice if you had one place where your whole team could plan requirements, assign tasks, start coding, collaborate, and deploy to your customers? If you didn’t have to fumble around deciding where you’re going to document user stories and requirement details?Andwhat if you could bring your designers and marketers into the conversation instead of having to collaborate with them through a separate medium?

Well, now you can! With Trello boards in Bitbucket Cloud, spin up a Trello board and get your entire team on the same page, instantly.

If you haven’t heard of Trello, well, get ready to get work done, fast. Trello’s boards, lists, and cards let you organize and prioritize projects in a fast, flexible way. Trello is one of the worlds most popular project planning and collaboration tools, and it’s now a core part of Bitbucket’s experience. Already, 14% of Bitbucket customers use Trello for planning their software projects, and we’ve made it even easier for teams to plan and track in the tool they already know and love. Give your team a shared workspace that takes you from planning to deploying with hackathon speed – for free.

Why use Trello boards in Bitbucket?

Everything in one place

With boards in Bitbucket, you now have one place for planning, tracking, collaborating on code, testing and deploying. Developers save time by never bouncing between multiple applications and losing context to find their next piece of work. You don’t have to add and configure user permissions in a separate tool because access to Trello boards can be set based on Bitbucket’s repository permissions. Keep work moving fast by having everything and everyone organized in one tool.

Simplify your workflow – create branches directly from cards

Plan projects on a Trello board and get to coding quickly by creating a branch straight from a Trello card. Create a pull request in Bitbucket and attach it to a card to keep everyone in the loop on the status. Pick your next card from a prioritized backlog on the board and move cards through your workflow to ensure all work is complete.

Get project status at a glance

Quickly understand the status of the team’s work in a simple, digestible view without navigating around Bitbucket to find related work. Gain total traceability with branches, commits, and pull requests all associated with cards on the board. Even see build and pull request status from the front of the card with color-coded card badges that help you recognize if there are any issues. Daily stand-ups are a breeze with information like status updates, code reviewers, and more all within the details of the card.

Collaborate with your team – no coding skills necessary!

PMs, engineers, designers, and marketers and many more contribute to the success of your product team. Extended teams now have a common language and workspace to collaborate on projects without needing to understand Bitbucket. Everyone can have one view of all their work without switching between multiple applications. Product teams can prioritize tasks and get perspective on the work getting done, and non-technical teams, like marketing, can see what’s shipping and share it with customers.

“The Trello integration with Bitbucket makes it easy for our developers to collaborate with our marketing team who want a fast and simple tool. They have access to our development backlog and can quickly add things like bugs, feature requests, or changes to the website.” – Alex Brown, Sr. Web Developer from Lushusa.com

We launched Bitbucket’s Trello Power-Up back in March. If you haven’t already, make sure to install it to take advantage of the full integration.

Using Bitbucket? Here’s how to get started

Trello boards are now available on all repositories in Bitbucket. Just navigate to a repo, click on the board menu item in the sidebar, and get started. If you already have a Trello account, you can select an existing board from the drop down or create a new board. If you want to have more than one board, go to the repository settings and attach a second or third board.

Need some inspiration?Use a Trello board for agile development, bug tracking, a product roadmap, sprint retrospectives and more. Check out some of Trello’s engineering use cases.

Using GitHub?

This is a great reason to try Bitbucket.

We have Trello integrated – obviously! Marketers and Designers don’t want to learn how to use GitHub issues.

Bitbucket has integrated CI/CD with Pipelines, so developers don’t spend time doing maintenance on Jenkins servers and GitHub integrations. With built-in Pipelines, see the status of your builds right in your repo. Take your code from testing to deploying in seconds.

]]>Bitbucket Pipelines can count! (Builds are now numbered)https://blog.bitbucket.org/2017/09/11/bitbucket-pipelines-can-count-builds-numbered/
Mon, 11 Sep 2017 17:10:05 +0000https://blog.bitbucket.org/?p=3456We’ve heard your feedback loud and clear – Bitbucket Pipelines needed build numbers, something you can use as a unique numeric identifier in your build and deployment pipeline. Today I’m happy to announce that we’ve shipped $BITBUCKET_BUILD_NUMBER – an incrementing build number for each build in your repository that is available as an environment variable. All previous builds have been numbered as well, and you’ll see the new number appearing in your Pipelines UI. Pipeline #23704, reporting for duty! A few neat things about this feature: $BITBUCKET_BUILD_NUMBER values will be unique across all branches, meaning you can use it as a software build number that won’t clash with builds on other branches rerunning a build will give it a new build number, also avoiding clashes and helping you track reruns better in the list of completed builds you can increment the build number to a new starting point using our REST API, which is handy if you’re moving from another tool. Note that this feature doesn’t aim to provide semantic versioning or branch-specific version numbers (i.e. version numbers for humans). You can find other tools out there that will do this for you, like the wonderful semantic-release. We hope you like this small but important addition to Pipelines.

Today I’m happy to announce that we’ve shipped $BITBUCKET_BUILD_NUMBER – an incrementing build number for each build in your repository that is available as an environment variable. All previous builds have been numbered as well, and you’ll see the new number appearing in your Pipelines UI.

Pipeline #23704, reporting for duty!

A few neat things about this feature:

$BITBUCKET_BUILD_NUMBER values will be unique across all branches, meaning you can use it as a software build number that won’t clash with builds on other branches

rerunning a build will give it a new build number, also avoiding clashes and helping you track reruns better in the list of completed builds

Note that this feature doesn’t aim to provide semantic versioning or branch-specific version numbers (i.e. version numbers for humans). You can find other tools out there that will do this for you, like the wonderful semantic-release.

]]>Bringing you speed, power and flexibility with 12 new features in Bitbucket Pipelines.https://blog.bitbucket.org/2017/08/22/bringing-speed-power-flexibility-12-new-features-bitbucket-pipelines/
Tue, 22 Aug 2017 16:56:05 +0000https://blog.bitbucket.org/?p=3436We launched Bitbucket Pipelines less than a year ago as a fully hosted CI/CD service that lives next to your code. By having Pipelines integrated with Bitbucket Cloud, setting it up is effortless – teams don’t need to sign up for another service, connect repositories or manage another set of users and permissions. We also manage all the build infrastructure for you, so builds start immediately when you add the configuration file to your repository. We’ve heard very positive feedback from customers and continue to invest in building innovative development tools. As teams have adopted Pipelines, our users have been clamoring for more and more functionality so they can use Pipelines to power more of their teams build and deployment tasks. So our team has been busy continuously improving Pipelines since launch, adding dozens of awesome features and improvements focused on speed, power, and flexibility. Today we wanted to look back and share some of the highlights – here are our top 12 features, all shipped in the last 6 months! Faster builds for faster feedback One of the key design principles of Pipelines is giving your developers the fastest feedback possible. Reducing development cycle time enables your team to move fast and fix problems quickly. As part of our ongoing mission to speed up your builds, we’ve made some major improvements in the last six months. Dependency caching – Pipelines now supports caching between builds, speeding up builds by up to 100%. Most builds start by downloading dependencies which takes a significant portion of the total build time. Builds can be faster if these dependencies aren’t downloaded each time. You can enable one of our pre-configured caches for popular tech stacks or configure your own. Alpine linux support – Alpine is a very lightweight Linux distribution weighing in at just 5 MB, so using it in your build can shave a significant amount off the download and startup time. All users can get the speed benefits of using any Docker image based on Alpine, including many of the official Docker images that started transitioning last year. Public image caching – Behind the scenes, Pipelines has recently started caching public Docker images, resulting in a noticeable boost to startup time to all builds running on our infrastructure. Command duration – You can now easily see which parts of your team’s pipeline are taking the longest, allowing you to optimize your build for speed. HipChat notifications – Respond quickly to failed builds by centralizing team notifications in HipChat or Slack and close your team’s development feedback loop. Leveraging the power of Docker containers Docker containers are hot in technology circles right now, and their benefits of isolation, portability and fast startup are a great fit for CI/CD. In the last six months, we’ve added advanced new Docker abilities to build, test and deploy your containerized applications through Pipelines. Build Docker images – Build your application Docker images, push them to a registry, then deploy – all directly from Pipelines. Every team can benefit from the portability and minimal overhead of containerization. One of our most popular feature requests! Service containers for database testing – Testing with databases like MySQL or services like Redis are a critical part of many CI setups. Service containers make it easy to run a database or service as a separate but linked container to your build, leveraging the open source containers available on DockerHub. Amazon ECR support – In addition to supporting all container registries using password authentication, Pipelines now supports pulling Docker images from Amazon ECR using the token authentication required by AWS. Simple yet flexible configuration Customize your continuous delivery workflow with additional flexibility within Bitbucket Pipelines and work the way you want. Scheduled pipelines – Rather than running a pipeline on every push, schedule a pipeline to run hourly, daily or weekly. This is great for running longer tests and scheduled jobs. SSH key management – No longer do you need to use arcane shell commands to generate and update SSH keys within your build script. Pipelines has a simple UI for creating or uploading an SSH key pair that is transparently injected into your build for easy access to external systems. Build numbers – Identify builds and version artifacts more easily with build numbers by using the $BITBUCKET_BUILD_NUMBER variable available in your build. bitbucket-pipelines.yml validator – Easily check for errors in your bitbucket-pipelines.yml before committing it to your repository with our validator. And this is just the beginning. Our team is hard at work building even more exciting Pipelines features for you in the coming months. There’s no better time to jump on board! Try Pipelines in Bitbucket today If you’re ready to start using Pipelines, sign up for a Bitbucket Cloud account and take it for a spin and tell us what you think! Already a Bitbucket customer? You can find Pipelines in the navigation menu on every Bitbucket repository. Get started, it’s free Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

]]>We launched Bitbucket Pipelines less than a year ago as a fully hosted CI/CD service that lives next to your code. By having Pipelines integrated with Bitbucket Cloud, setting it up is effortless – teams don’t need to sign up for another service, connect repositories or manage another set of users and permissions. We also manage all the build infrastructure for you, so builds start immediately when you add the configuration file to your repository. We’ve heard very positive feedback from customers and continue to invest in building innovative development tools.

As teams have adopted Pipelines, our users have been clamoring for more and more functionality so they can use Pipelines to power more of their teams build and deployment tasks. So our team has been busy continuously improving Pipelines since launch, adding dozens of awesome features and improvements focused on speed, power, and flexibility.

Today we wanted to look back and share some of the highlights – here are our top 12 features, all shipped in the last 6 months!

Faster builds for faster feedback

One of the key design principles of Pipelines is giving your developers the fastest feedback possible. Reducing development cycle time enables your team to move fast and fix problems quickly. As part of our ongoing mission to speed up your builds, we’ve made some major improvements in the last six months.

Dependency caching – Pipelines now supports caching between builds, speeding up builds by up to 100%. Most builds start by downloading dependencies which takes a significant portion of the total build time. Builds can be faster if these dependencies aren’t downloaded each time. You can enable one of our pre-configured caches for popular tech stacks or configure your own.

Alpine linux support – Alpine is a very lightweight Linux distribution weighing in at just 5 MB, so using it in your build can shave a significant amount off the download and startup time. All users can get the speed benefits of using any Docker image based on Alpine, including many of the official Docker images that started transitioning last year.

Public image caching – Behind the scenes, Pipelines has recently started caching public Docker images, resulting in a noticeable boost to startup time to all builds running on our infrastructure.

Command duration – You can now easily see which parts of your team’s pipeline are taking the longest, allowing you to optimize your build for speed.

Leveraging the power of Docker containers

Docker containers are hot in technology circles right now, and their benefits of isolation, portability and fast startup are a great fit for CI/CD. In the last six months, we’ve added advanced new Docker abilities to build, test and deploy your containerized applications through Pipelines.

Build Docker images – Build your application Docker images, push them to a registry, then deploy – all directly from Pipelines. Every team can benefit from the portability and minimal overhead of containerization. One of our most popular feature requests!

Service containers for database testing – Testing with databases like MySQL or services like Redis are a critical part of many CI setups. Service containers make it easy to run a database or service as a separate but linked container to your build, leveraging the open source containers available on DockerHub.

Amazon ECR support – In addition to supporting all container registries using password authentication, Pipelines now supports pulling Docker images from Amazon ECR using the token authentication required by AWS.

Simple yet flexible configuration

Customize your continuous delivery workflow with additional flexibility within Bitbucket Pipelines and work the way you want.

Scheduled pipelines – Rather than running a pipeline on every push, schedule a pipeline to run hourly, daily or weekly. This is great for running longer tests and scheduled jobs.

SSH key management – No longer do you need to use arcane shell commands to generate and update SSH keys within your build script. Pipelines has a simple UI for creating or uploading an SSH key pair that is transparently injected into your build for easy access to external systems.

Build numbers – Identify builds and version artifacts more easily with build numbers by using the $BITBUCKET_BUILD_NUMBER variable available in your build.

bitbucket-pipelines.yml validator – Easily check for errors in your bitbucket-pipelines.yml before committing it to your repository with our validator.

And this is just the beginning. Our team is hard at work building even more exciting Pipelines features for you in the coming months. There’s no better time to jump on board!

]]>Kickstart your DevOps journey with JIRA Software and Bitbucket Server 5.3https://blog.bitbucket.org/2017/08/22/bitbucket-server-5-3-jira-software-integration/
Tue, 22 Aug 2017 16:30:57 +0000https://blog.bitbucket.org/?p=3431DevOps is built on a set of 3 underlying principles that impact your success (a.k.a the 3 ways of DevOps) – flow, feedback, and experimentation. During your DevOps journey, the 3 ways impact how you think about work, how you interact with your team – and extended team – and the practices you put into place. When all 3 of these things are working together, development and operations teams produce and deliver higher quality software together, with less stress and lower risk. In any DevOps transformation, teams need to think about how they work together – their culture must foster an environment where the 3 ways can thrive. Only then can the supporting processes, tools, and technology reinforce the collaborative mindset. When it comes to development tools, Bitbucket Server & Data Center can help with all 3 ways, but today we’re going to focus on flow through one core element – integration with JIRA Software. In Bitbucket Server and Data Center 5.3, available today, JIRA Software’s best version control integration gets even better with the ability to create JIRA Software issues from inside Bitbucket’s pull requests. The impact of integration on flow Making sure work in progress is clearly tracked and visible to stakeholders through your development process can be time-consuming and error-prone without the right tools working together for you. Information requirements can be narrow, like a team lead looking at the development progress behind a single issue, commit or code review, or very broad, like an operations team looking at release readiness across entire projects or business units. No matter the scope, JIRA Software and Bitbucket maximize the visibility of work throughout the development process, connecting planned work to code changes, builds and deployments. More time can be saved through specific integrations tuned to your workflow. Depending on your teams way of working, you can transition JIRA issue status manually from a pull request in Bitbucket, directly via Git commit messages, or automatically using workflow triggers, i.e. when a pull request is created move an issue from ‘in-progress’ to ‘in-review’. In short, simplifying manual tasks and automating repetitive tasks increases consistency, reduces frustration, and avoids delays. New in Bitbucket Server 5.3 – Create an issue from a pull request While it’s fantastic to be able to track an idea from issue to production in a way that suits your team’s needs, there are problems that arise during development that need to feed back into the whole cycle as a separate issue. A classic example is during a code review, a.k.a pull request in Bitbucket. Teams often notice something that isn’t quite right during the review, but the improvement isn’t something to be dealt with as part of the pull request in question. Maybe you’ve uncovered a refactoring opportunity or remembered a task long forgotten, something that should be captured in your issue tracker so it doesn’t get ignored anymore. In each case, developers have to stop what they’re doing, open JIRA Software, create a new issue for later consideration, and then paste the issue link into a comment on the pull request to make it visible to others. In Bitbucket Server 5.3 flow gets a boost with the ability to create JIRA Software issues directly from a pull request comment in Bitbucket. Next time you notice something that needs to be fixed, save yourself a trip to JIRA Software and create the issue in-line inside of Bitbucket. The integration handles all the hard work for you, just hit the ‘Create JIRA issue’ button in your comment, fill in the prompts, and go back to reviewing. Your tooling matters The tooling you select to support your DevOps journey won’t automatically transform your business, but it can certainly help make that transition easier. Ultimately the way you manage your source code should complement how you’re tracking the work to be done. Being able to capture new issues quickly keeps teams in flow. By choosing Bitbucket Server and JIRA Software you’re getting a head start. Give Bitbucket Server 5.3 a try and see how deeper integrations with your version control can change how you work. Download Bitbucket Server 5.3 To learn more about creating a JIRA issue from a pull request and other improvements and bug fixes in 5.3, see our release notes.

DevOps is built on a set of 3 underlying principles that impact your success (a.k.a the 3 ways of DevOps) – flow, feedback, and experimentation. During your DevOps journey, the 3 ways impact how you think about work, how you interact with your team – and extended team – and the practices you put into place. When all 3 of these things are working together, development and operations teams produce and deliver higher quality software together, with less stress and lower risk.

In any DevOps transformation, teams need to think about how they work together – their culture must foster an environment where the 3 ways can thrive. Only then can the supporting processes, tools, and technology reinforce the collaborative mindset.

When it comes to development tools, Bitbucket Server & Data Center can help with all 3 ways, but today we’re going to focus on flow through one core element – integration with JIRA Software. In Bitbucket Server and Data Center 5.3, available today, JIRA Software’s best version control integration gets even better with the ability to create JIRA Software issues from inside Bitbucket’s pull requests.

The impact of integration on flow

Making sure work in progress is clearly tracked and visible to stakeholders through your development process can be time-consuming and error-prone without the right tools working together for you. Information requirements can be narrow, like a team lead looking at the development progress behind a single issue, commit or code review, or very broad, like an operations team looking at release readiness across entire projects or business units. No matter the scope, JIRA Software and Bitbucket maximize the visibility of work throughout the development process, connecting planned work to code changes, builds and deployments.

More time can be saved through specific integrations tuned to your workflow. Depending on your teams way of working, you can transition JIRA issue status manually from a pull request in Bitbucket, directly via Git commit messages, or automatically using workflow triggers, i.e. when a pull request is created move an issue from ‘in-progress’ to ‘in-review’.

New in Bitbucket Server 5.3 – Create an issue from a pull request

While it’s fantastic to be able to track an idea from issue to production in a way that suits your team’s needs, there are problems that arise during development that need to feed back into the whole cycle as a separate issue. A classic example is during a code review, a.k.a pull request in Bitbucket. Teams often notice something that isn’t quite right during the review, but the improvement isn’t something to be dealt with as part of the pull request in question. Maybe you’ve uncovered a refactoring opportunity or remembered a task long forgotten, something that should be captured in your issue tracker so it doesn’t get ignored anymore. In each case, developers have to stop what they’re doing, open JIRA Software, create a new issue for later consideration, and then paste the issue link into a comment on the pull request to make it visible to others.

In Bitbucket Server 5.3 flow gets a boost with the ability to create JIRA Software issues directly from a pull request comment in Bitbucket. Next time you notice something that needs to be fixed, save yourself a trip to JIRA Software and create the issue in-line inside of Bitbucket.

The integration handles all the hard work for you, just hit the ‘Create JIRA issue’ button in your comment, fill in the prompts, and go back to reviewing.

Your tooling matters

The tooling you select to support your DevOps journey won’t automatically transform your business, but it can certainly help make that transition easier. Ultimately the way you manage your source code should complement how you’re tracking the work to be done. Being able to capture new issues quickly keeps teams in flow.

By choosing Bitbucket Server and JIRA Software you’re getting a head start. Give Bitbucket Server 5.3 a try and see how deeper integrations with your version control can change how you work.

]]>Scheduled pipelines now available in Bitbucket Pipelineshttps://blog.bitbucket.org/2017/08/16/scheduled-pipelines-now-available-bitbucket-pipelines/
Wed, 16 Aug 2017 16:38:33 +0000https://blog.bitbucket.org/?p=3423Bitbucket Pipelines makes it quick and easy to get fast feedback when changes are committed. However, there are many use cases where builds need to be run on both changes to the code base and on a regular schedule. Some examples include: Nightly builds that take longer to run Daily or weekly deployments to a test environment Data validation and backups Load tests and tracking performance over time Jobs and tasks that aren’t coupled to code changes We’re excited to announce that you can now run pipelines on a schedule. This is another highly requested feature by our users. Creating a schedule is easy. Just define a custom pipeline in your bitbucket-pipelines.yml configuration. Then create a schedule for a branch from the main Pipelines view. Pipelines can be configured to run on an hourly, daily or weekly schedule. Happy building! Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

]]>Bitbucket Pipelines makes it quick and easy to get fast feedback when changes are committed. However, there are many use cases where builds need to be run on both changes to the code base and on a regular schedule. Some examples include:

Nightly builds that take longer to run

Daily or weekly deployments to a test environment

Data validation and backups

Load tests and tracking performance over time

Jobs and tasks that aren’t coupled to code changes

We’re excited to announce that you can now run pipelines on a schedule. This is another highly requested feature by our users. Creating a schedule is easy. Just define a custom pipeline in your bitbucket-pipelines.yml configuration. Then create a schedule for a branch from the main Pipelines view.

Pipelines can be configured to run on an hourly, daily or weekly schedule.

Happy building!

Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

]]>4 features in 4 weeks: here’s what’s new in Bitbucket Cloudhttps://blog.bitbucket.org/2017/07/27/4-features-in-4-weeks-heres-whats-new-in-bitbucket-cloud/
Thu, 27 Jul 2017 19:49:22 +0000https://blog.bitbucket.org/?p=3408Machines are cheap, but your time isn’t. Throughout your day, every tedious task adds up. Individually reverting each commit in the command line after a mistake, searching forever for an important part of your code during a review, or waiting on a build to finish can be culprits that contribute to an unproductive day. We want to make your job easier, which means helping you manage your time and productivity. In the past month we’ve been busy releasing 4 new features that are going to get you out of the office that much sooner. Revert merged pull requests: At some point, we’ve all merged code we wish we could take back. Luckily, git revert has always allowed you to revert mistakes in the command line. But if this mistake you’re reverting involves a pull request, reverting this in the UI is much easier, and necessary for quick access. Today we’re adding the ability to revert a pull request that was merged on a Git repository in Bitbucket’s user interface. Instead of automatically reverting all commits (which can lose any changes that’ve been made since that merge), a new pull request will be created that has to go through an approval process. That revert pull request will suggest all recent approvers (plus anyone else you would like to add), and help ensure that all proper merge checks are met prior to reverting. This will keep all team members in the loop and keep all the changes made by any team member. Check out revert merged pull request documentation here. Commit API Our most popular add-ons like AWS CodeDeploy make it easier for developers to complete their workflow within Bitbucket, save time and increase productivity. However, our add-ons were missing the ability to look deeper into your commits. Without this, certain processes like creating files were manual, and therefore more time consuming. We want to empower our users with the integrations they need so we created a commit API to help with this. This API allows developers to integrate Bitbucket in to external services and retrieve information normally accessed in the command line or commit: The commit API allows read and write access to files and directories at any point in the repository history (by specifying commit, tag, or branch name) using only authenticated HTTP requests. Add-ons can preform actions that previously weren’t available, like creating files, creating a commit, reading files or commits (and preforming actions based on this information), and pushing. Repository agnostic (i.e. does not matter if the repo is GIT or Mercurial) so add-ons can be created for all of our users. By enabling add-on developers with the commit API, we’ve opened up more data to add-ons that give you more possibilities with them. As a result, we have several 3rd parties working on new integrations. Keep a look out for a new Jenkins integration and more that are using the commit API and check out the API if you are interested in making an add-on. Syntax highlighting in code search Bitbucket Cloud launched a Beta of our #1 highest voted feature in May: code search. Our code aware search saves you time combing through usage results with a semantic search that ranks definitions first over usages or variables names. It first launched with viewing search results in plain text, and combing through a sea of unformatted text results can be tedious and can take longer to find what you’re looking for. In this next iteration of code search, we wanted to simplify search results so they are easily scannable with syntax highlighting in our code aware search. This helps when reading and reviewing code because you can track the most important parts, without having to go through it with a fine-tooth comb. Check out code aware search documentation here. Before After Dependency Caching in Bitbucket Pipelines Bitbucket Pipelines is our built-in continuous delivery service that runs builds in Docker containers. This gives you the benefit of your build scripts executing much sooner than running them on Virtual Machines, and ultimately means builds aren’t waiting in a queue. With this model, we noticed faster build times than a CI tool that requires a server, but still not as fast as we’d like. Between builds, dependencies needed to be downloaded each time, which tacked on time per build. Not awesome. By adding support for caching between builds in Pipelines, we saw build times reduced by up to 50%. This addition should have you waiting less on build times. To get you started, we have pre-defined caches for popular build tools or you can create a custom cache here. Check out the caching dependencies documentation here. Try Bitbucket’s newest features If you’re ready to start using any of these features, sign up for a Bitbucket Cloud account and take them for a spin. Already a Bitbucket customer? refer to the feature documentation to get going. Get started, it’s free Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

]]>Machines are cheap, but your time isn’t. Throughout your day, every tedious task adds up. Individually reverting each commit in the command line after a mistake, searching forever for an important part of your code during a review, or waiting on a build to finish can be culprits that contribute to an unproductive day.

We want to make your job easier, which means helping you manage your time and productivity. In the past month we’ve been busy releasing 4 new features that are going to get you out of the office that much sooner.

Revert merged pull requests:

At some point, we’ve all merged code we wish we could take back. Luckily, git revert has always allowed you to revert mistakes in the command line. But if this mistake you’re reverting involves a pull request, reverting this in the UI is much easier, and necessary for quick access.

Today we’re adding the ability to revert a pull request that was merged on a Git repository in Bitbucket’s user interface. Instead of automatically reverting all commits (which can lose any changes that’ve been made since that merge), a new pull request will be created that has to go through an approval process. That revert pull request will suggest all recent approvers (plus anyone else you would like to add), and help ensure that all proper merge checks are met prior to reverting. This will keep all team members in the loop and keep all the changes made by any team member. Check out revert merged pull request documentation here.

Commit API

Our most popular add-ons like AWS CodeDeploy make it easier for developers to complete their workflow within Bitbucket, save time and increase productivity. However, our add-ons were missing the ability to look deeper into your commits. Without this, certain processes like creating files were manual, and therefore more time consuming. We want to empower our users with the integrations they need so we created a commit API to help with this. This API allows developers to integrate Bitbucket in to external services and retrieve information normally accessed in the command line or commit:

The commit API allows read and write access to files and directories at any point in the repository history (by specifying commit, tag, or branch name) using only authenticated HTTP requests.

Add-ons can preform actions that previously weren’t available, like creating files, creating a commit, reading files or commits (and preforming actions based on this information), and pushing.

Repository agnostic (i.e. does not matter if the repo is GIT or Mercurial) so add-ons can be created for all of our users.

By enabling add-on developers with the commit API, we’ve opened up more data to add-ons that give you more possibilities with them. As a result, we have several 3rd parties working on new integrations.Keep a look out for a new Jenkins integration and more that are using the commit API and check out the API if you are interested in making an add-on.

Syntax highlighting in code search

Bitbucket Cloud launched a Beta of our #1 highest voted feature in May: code search. Our code aware search saves you time combing through usage results with a semantic search that ranks definitions first over usages or variables names. It first launched with viewing search results in plain text, and combing through a sea of unformatted text results can be tedious and can take longer to find what you’re looking for.

In this next iteration of code search, we wanted to simplify search results so they are easily scannable with syntax highlighting in our code aware search. This helps when reading and reviewing code because you can track the most important parts, without having to go through it with a fine-tooth comb. Check out code aware search documentation here.

Before

After

Dependency Caching in Bitbucket Pipelines

Bitbucket Pipelines is our built-in continuous delivery service that runs builds in Docker containers. This gives you the benefit of your build scripts executing much sooner than running them on Virtual Machines, and ultimately means builds aren’t waiting in a queue. With this model, we noticed faster build times than a CI tool that requires a server, but still not as fast as we’d like. Between builds, dependencies needed to be downloaded each time, which tacked on time per build. Not awesome.

By adding support for caching between builds in Pipelines, we saw build times reduced by up to 50%. This addition should have you waiting less on build times. To get you started, we have pre-defined caches for popular build tools or you can create a custom cache here. Check out the caching dependencies documentation here.

Try Bitbucket’s newest features

If you’re ready to start using any of these features, sign up for a Bitbucket Cloud account and take them for a spin. Already a Bitbucket customer? refer to the feature documentation to get going.

]]>Bitbucket Server 5.2: Compliance meets DevOpshttps://blog.bitbucket.org/2017/07/18/bitbucket-server-5-2-compliance-meets-devops/
Tue, 18 Jul 2017 14:00:18 +0000https://blog.bitbucket.org/?p=3400Version control is at the heart of every development team’s process. The version control tooling and technology you select not only dictate how you interact with your team, but can also hold you back from making improvements to your workflow. For example, teams looking to adopt DevOps practices can be especially frustrated with the lack of tooling options if they are also facing organization compliance requirements (e.g. audit trails, mandated workflows, and permission structures). To comply you may get stuck using older homegrown solutions or must continue following inefficient development patterns. Bitbucket Server & Data Center bring the best of both worlds – Git repository management focused on speed, collaboration, and quality with the security, traceability, and scale required to fulfill meaty compliance rules. Today we’re introducing project level administration, an additional tool for ensuring compliance regulations can be met without the burden of constant monitoring by administrators. Keep reading to learn more about project level administration and an update to Bitbucket Data Center smart mirroring in 5.2. Download Bitbucket Server 5.2 Project level administration Bitbucket Server is built for professional software teams, providing more ways to customize and secure your workflows than other Git management tools. For any repository, administrators can configure the branching model, the type of merge strategy used for pull requests, mandate that all commits be GPG signed and/or pushed only by the commit author, restrict branch access, and more. All of which play a role in ensuring compliance requirements are met without the team having to worry about it. Until today things like hooks, branch permissions and model, and pull request merge checks had to be configured each time a new repository was created. In organizations with teams that create hundreds or thousands of repositories, this leads to wasted time or security holes by granting repository admin access to folks who originally may not have needed it. With the introduction of project level administration, these settings can now be applied to all the repositories in a project at once. Project level administration works in much of the same way that repository settings do. Any user who’s been granted project level administration rights can edit the settings for the project, which will apply to all the repositories stored within. New repositories created will instantly inherit settings from the project level. However, if a repository has unique requirements, the repo administrator can modify specific settings by overriding the project level configuration. For more information on project level administration, see our release notes. Smart mirror push proxy Smart mirrors in Bitbucket Data Center help global teams speed up pull operations in high-latency and low-bandwidth environments. These read-only copies of repositories stay updated automatically and inherit all the rules and permissions configured on the master server. Previously, continuous integration servers and developers using mirrors needed to maintain 2 URLs, one for fetching from the mirror and the other for pushing to the primary server. In Bitbucket Data Center 5.2, we’re introducing push proxying, which combines both operations into a single HTTP or SSH URL – one less thing to worry about in your day to day development activities. Compliance meets DevOps Adopting DevOps practices while maintaining a secure, traceable, and scalable development environment is possible. The tooling you select shouldn’t hold you back from making positive changes, it should enable them. Bitbucket Server 5.2 can help your team take advantage of the best DevOps has to offer while complying with organizational policies. Create a workflow that works for your team minus the auditing and compliance headaches. It’s a win-win all around. Download Bitbucket Server 5.2

]]>Version control is at the heart of every development team’s process. The version control tooling and technology you select not only dictate how you interact with your team, but can also hold you back from making improvements to your workflow. For example, teams looking to adopt DevOps practices can be especially frustrated with the lack of tooling options if they are also facing organization compliance requirements (e.g. audit trails, mandated workflows, and permission structures). To comply you may get stuck using older homegrown solutions or must continue following inefficient development patterns.

Bitbucket Server & Data Center bring the best of both worlds – Git repository management focused on speed, collaboration, and quality with the security, traceability, and scale required to fulfill meaty compliance rules. Today we’re introducing project level administration, an additional tool for ensuring compliance regulations can be met without the burden of constant monitoring by administrators.

Keep reading to learn more about project level administration and an update to Bitbucket Data Center smart mirroring in 5.2.

Project level administration

Bitbucket Server is built for professional software teams, providing more ways to customize and secure your workflows than other Git management tools. For any repository, administrators can configure the branching model, the type of merge strategy used for pull requests, mandate that all commits be GPG signed and/or pushed only by the commit author, restrict branch access, and more. All of which play a role in ensuring compliance requirements are met without the team having to worry about it.

Until today things like hooks, branch permissions and model, and pull request merge checks had to be configured each time a new repository was created. In organizations with teams that create hundreds or thousands of repositories, this leads to wasted time or security holes by granting repository admin access to folks who originally may not have needed it. With the introduction of project level administration, these settings can now be applied to all the repositories in a project at once.

Project level administration works in much of the same way that repository settings do. Any user who’s been granted project level administration rights can edit the settings for the project, which will apply to all the repositories stored within. New repositories created will instantly inherit settings from the project level. However, if a repository has unique requirements, the repo administrator can modify specific settings by overriding the project level configuration. For more information on project level administration, see our release notes.

Smart mirror push proxy

Smart mirrors in Bitbucket Data Center help global teams speed up pull operations in high-latency and low-bandwidth environments. These read-only copies of repositories stay updated automatically and inherit all the rules and permissions configured on the master server. Previously, continuous integration servers and developers using mirrors needed to maintain 2 URLs, one for fetching from the mirror and the other for pushing to the primary server. In Bitbucket Data Center 5.2, we’re introducing push proxying, which combines both operations into a single HTTP or SSH URL – one less thing to worry about in your day to day development activities.

Compliance meets DevOps

Adopting DevOps practices while maintaining a secure, traceable, and scalable development environment is possible. The tooling you select shouldn’t hold you back from making positive changes, it should enable them. Bitbucket Server 5.2 can help your team take advantage of the best DevOps has to offer while complying with organizational policies. Create a workflow that works for your team minus the auditing and compliance headaches. It’s a win-win all around.

]]>Confessions of a Git wallflower, and other stories about Bitbuckethttps://blog.bitbucket.org/2017/06/30/confessions-git-wallflower-stories-bitbucket/
Fri, 30 Jun 2017 18:19:26 +0000https://blog.bitbucket.org/?p=3393This post comes from Abhishek Sharma, a Masters of Science student at the University of Southampton and member of Bitbucket’s Student Amabassador team. “Code collaboration on steroids” — this is how Atlassian describe Bitbucket on their site. And this is exactly what I experienced first-hand when I lost my Git virginity after being introduced to Bitbucket in September last year. I’ll tell you the story in a moment, but if you’d prefer to just cut to the chase… Anyone can use Bitbucket for free. But university students and staff can upgrade to the premium offering at no extra charge (take that, student debt!). There’s a party going on over here, and you’re all invited. So. On with my story. For one of my Master of Science modules in the first semester, we were tasked with a group project. I know, I know… the dreaded group project. We had to create a trading agent that could perform the bidding strategy of advertising networks in the AdX TAC (a virtual platform for simulating an ad exchange marketplace) by automatically placing ad bids that would ensure the largest revenue and profits are generated by winning as many campaigns as possible – preferably big campaigns. We also had to minimise the costs incurred to fulfill said campaigns. My group’s agent would then compete with 24 other agents in a 7-hour trading competition where, despite our best efforts, it would end up placing 14th. Simply because we opted for a rational strategy instead of exploiting the randomness factor in the competition… but that is a discussion better left for another day. So, after an endless amount of reading and understanding what it is we were required to do, one of the members (who also happens to be one of the most hard-working people I’ve had the pleasure of befriending in my short life so far) of our team recommended we use Bitbucket to manage our project. Now, at the time, I was only familiar with GitHub and thought of it as just a means for finding similar projects to whatever coding assignment I may be working on at that point. Creating an actual repository and collaborating with others on a big project like this was the equivalent of walking into a department mixer where everyone knows each other’s names – except you. Not to mention that I had never worked on a group coding project before, let alone use a Version Control System (VCS) to manage it. Not surprisingly, the whole situation so overwhelmed by my brain that I started second-guess my coding skills and even my decision to pursue a MSc in the first place. My teammates were doing the Git equivalent of drinking me under the table. Thankfully, however, they were kind and patient enough to put up with my inexperience. They answered all the stupid questions I asked regarding Bitbucket, Git, and the project in general – thus helping me realise the importance of Git in the process. Once the project was over and submitted, I realised just how insignificant my contributions had been thanks to my lack of experience with Git. It was around this point when I strolled across the Bitbucket tutorials. Through them, I finally learnt how to create a repository via the Git terminal rather than creating one directly from the Bitbucket site. Yes: despite having an undergraduate degree in software engineering, I had so little exposure to Git that even being able to use Git Bash to do simple things like clone, pull, and push commits was mind-blowing for me. Fast-forward to today, and the tutorials have made me so confident using Git that the first step I take now before embarking on any coding venture is to create a repository. Not only does this allow me to make my projects available to potential collaborators, it also helps me direct potential employers to the coding projects I have worked on (or am currently working on). It’s nice to be able to prove that I truly possess the technical skills I claim to have on my resume. Although it is through Bitbucket that I learnt (and am currently in the process of mastering) the wonders of Git, most of my projects are currently based on GitHub right now. But I’ve already started migrating these to Bitbucket and make that my primary tool for project management. Why, you ask? Well, it’s simple. The free version of Bitbucket offers loads more features to play with than the free version of GitHub. For example, Bitbucket have recently introduced a feature called code-aware search, which is an easy way to comb through large repositories and code bases. As a bonus, it forces you to get into the good habit of writing good, reusable code so that the semantic search algorithm used by the feature can return results in a ranked format. From what I know, GitHub does not offer this (or maybe you have pay for it). Also, Bitbucket offers free academic licenses for students and professors, which lets you create unlimited repositories (both public and private) along with the ability to add an unlimited amount of collaborators. Seriously. It’s free, as long as you are a student at one of the academic institutions that Bitbucket offers these licenses to. And if your school isn’t on their list yet, you can get on the list here. So that’s my story. I’d spent my entire undergrad career knowing that there’s this massive party called Git that everybody was going to, but too shy (and/or) busy to get myself invited to it. Thank you, Bitbucket, for pulling me in. Calling all university students and professors! Learn how Bitbucket’s free academic license program can help your next project or class. Git educated (see what we did there?)

This post comes from Abhishek Sharma, a Masters of Science student at the University of Southampton and member of Bitbucket’s Student Amabassador team.

“Code collaboration on steroids” — this is how Atlassian describe Bitbucket on their site. And this is exactly what I experienced first-hand when I lost my Git virginity after being introduced to Bitbucket in September last year. I’ll tell you the story in a moment, but if you’d prefer to just cut to the chase…

For one of my Master of Science modules in the first semester, we were tasked with a group project. I know, I know… the dreaded group project. We had to create a trading agent that could perform the bidding strategy of advertising networks in the AdX TAC (a virtual platform for simulating an ad exchange marketplace) by automatically placing ad bids that would ensure the largest revenue and profits are generated by winning as many campaigns as possible – preferably big campaigns. We also had to minimise the costs incurred to fulfill said campaigns.

My group’s agent would then compete with 24 other agents in a 7-hour trading competition where, despite our best efforts, it would end up placing 14th. Simply because we opted for a rational strategy instead of exploiting the randomness factor in the competition… but that is a discussion better left for another day.

So, after an endless amount of reading and understanding what it is we were required to do, one of the members (who also happens to be one of the most hard-working people I’ve had the pleasure of befriending in my short life so far) of our team recommended we use Bitbucket to manage our project.

Now, at the time, I was only familiar with GitHub and thought of it as just a means for finding similar projects to whatever coding assignment I may be working on at that point. Creating an actual repository and collaborating with others on a big project like this was the equivalent of walking into a department mixer where everyone knows each other’s names – except you.

Not to mention that I had never worked on a group coding project before, let alone use a Version Control System (VCS) to manage it. Not surprisingly, the whole situation so overwhelmed by my brain that I started second-guess my coding skills and even my decision to pursue a MSc in the first place. My teammates were doing the Git equivalent of drinking me under the table.

Thankfully, however, they were kind and patient enough to put up with my inexperience. They answered all the stupid questions I asked regarding Bitbucket, Git, and the project in general – thus helping me realise the importance of Git in the process.

Once the project was over and submitted, I realised just how insignificant my contributions had been thanks to my lack of experience with Git. It was around this point when I strolled across the Bitbucket tutorials. Through them, I finally learnt how to create a repository via the Git terminal rather than creating one directly from the Bitbucket site. Yes: despite having an undergraduate degree in software engineering, I had so little exposure to Git that even being able to use Git Bash to do simple things like clone, pull, and push commits was mind-blowing for me.

Fast-forward to today, and the tutorials have made me so confident using Git that the first step I take now before embarking on any coding venture is to create a repository. Not only does this allow me to make my projects available to potential collaborators, it also helps me direct potential employers to the coding projects I have worked on (or am currently working on). It’s nice to be able to prove that I truly possess the technical skills I claim to have on my resume.

Although it is through Bitbucket that I learnt (and am currently in the process of mastering) the wonders of Git, most of my projects are currently based on GitHub right now. But I’ve already started migrating these to Bitbucket and make that my primary tool for project management.

Why, you ask? Well, it’s simple. The free version of Bitbucket offers loads more features to play with than the free version of GitHub.

For example, Bitbucket have recently introduced a feature called code-aware search, which is an easy way to comb through large repositories and code bases. As a bonus, it forces you to get into the good habit of writing good, reusable code so that the semantic search algorithm used by the feature can return results in a ranked format. From what I know, GitHub does not offer this (or maybe you have pay for it).

Also, Bitbucket offers free academic licenses for students and professors, which lets you create unlimited repositories (both public and private) along with the ability to add an unlimited amount of collaborators. Seriously. It’s free, as long as you are a student at one of the academic institutions that Bitbucket offers these licenses to. And if your school isn’t on their list yet, you can get on the list here.

So that’s my story. I’d spent my entire undergrad career knowing that there’s this massive party called Git that everybody was going to, but too shy (and/or) busy to get myself invited to it. Thank you, Bitbucket, for pulling me in.

Calling all university students and professors! Learn how Bitbucket’s free academic license program can help your next project or class.

]]>Faster builds with dependency cachinghttps://blog.bitbucket.org/2017/06/27/faster-builds-dependency-caching/
Tue, 27 Jun 2017 18:17:12 +0000https://blog.bitbucket.org/?p=3385One of the key principles behind the design of Pipelines was quick developer feedback on changes committed. After all, machines are cheap but your developers’ time isn’t. This principle influenced how we chose to price pipelines to provide unlimited concurrency, so builds aren’t waiting in a queue. Running builds in Docker containers also means your build scripts start executing much sooner than running them on VMs. With most languages, builds start by downloading dependencies, accounting for a significant time of each build. Between each build, dependencies seldom change and when they do, it is usually incremental. Builds can be faster if dependencies don‘t need to be downloaded each time. Today, we are excited to announce that Pipelines supports caching between builds. For early adopters in our Alpha group, we have seen builds reduced by up to 50% in build time (and build minutes)! Adding a cache is simple. Here’s an example for adding a cache for node_modules. image: node:8 pipelines: default: - step: caches: - node script: - npm install - npm test We’ve pre-defined caches for several popular build tools. If your build tool doesn’t have a pre-defined cache, you can still define a custom cache in your bitbucket-pipelines.yml file. Caches are per repository and can be shared between your pipelines. With this addition, we hope your developers are waiting less and coding more! Enabled caching already? Tell us on Twitter @Bitbucket how much it has shaved off your build time.

]]>One of the key principles behind the design of Pipelines was quick developer feedback on changes committed. After all, machines are cheap but your developers’ time isn’t. This principle influenced how we chose to price pipelines to provide unlimited concurrency, so builds aren’t waiting in a queue. Running builds in Docker containers also means your build scripts start executing much sooner than running them on VMs.

With most languages, builds start by downloading dependencies, accounting for a significant time of each build. Between each build, dependencies seldom change and when they do, it is usually incremental. Builds can be faster if dependencies don‘t need to be downloaded each time.

Today, we are excited to announce that Pipelines supports caching between builds. For early adopters in our Alpha group, we have seen builds reduced by up to 50% in build time (and build minutes)!

Adding a cache is simple. Here’s an example for adding a cache for node_modules.

We’ve pre-defined caches for several popular build tools. If your build tool doesn’t have a pre-defined cache, you can still define a custom cache in your bitbucket-pipelines.yml file. Caches are per repository and can be shared between your pipelines.

With this addition, we hope your developers are waiting less and coding more!

Enabled caching already? Tell us on Twitter @Bitbucket how much it has shaved off your build time.

]]>New outbound IP addresses for webhookshttps://blog.bitbucket.org/2017/06/21/new-outbound-ip-addresses-webhooks/
Wed, 21 Jun 2017 17:28:41 +0000https://blog.bitbucket.org/?p=3384Bitbucket webhooks are used by teams every day to test, analyze, deploy, and distribute great software to millions of people. In a few weeks, we will be making a change to our network configuration that results in these services routing through different IP addresses. We plan to make this change no earlier than Monday July 10th. If you’re using webhooks and have firewall rules to allow Bitbucket to communicate with your servers, you’ll need to add the new IPs to your rules before Monday July 10th. The current source IP address range is: 104.192.143.0/24 The new source IP addresses will be: 34.198.203.127 34.198.178.64 34.198.32.85 As always, you can consult our documentation for the current list of supported IPs for webhooks.

]]>Bitbucket webhooks are used by teams every day to test, analyze, deploy, and distribute great software to millions of people.

In a few weeks, we will be making a change to our network configuration that results in these services routing through different IP addresses. We plan to make this change no earlier than Monday July 10th.

If you’re using webhooks and have firewall rules to allow Bitbucket to communicate with your servers, you’ll need to add the new IPs to your rules before Monday July 10th.