By Raj Sarkar on January 6, 2017
[This guest post is written by Jesse Gibbs, Head of Product at Rollbar. Jesse is a developer turned product manager who has spent 15+ years at companies building tools for software development, devops, and QA teams.]
Rollbar notifies developers in real-time when critical errors occur in their production apps. And now, Rollbar integrates with Git repositories and issue tracking in Bitbucket so that developers can troubleshoot and fix errors fast, ensuring that important errors don’t slip through the cracks.
Let’s take a look at how this works:
Deep links to source code in stack traces
Every Rollbar error report includes a full stack trace. With Rollbar connected to your Bitbucket Git repo, the stack trace entries become URLs linking to the exact line of code in source file.
When troubleshooting critical, customer-facing errors, developers can jump immediately from stack trace to source code, saving valuable time when every second counts.
Correlate Errors to Deploys
It’s easy to notify Rollbar every time you deploy to production or release a new version of your app. Rollbar integrates with Bitbucket Pipelines, and you can easily track deploys with other tools. Tracking deploys unlocks several valuable features in Rollbar that will make root cause analysis easier.
With deploy tracking enabled, Rollbar will tell you which deploy preceded the first occurrence of an error, or a re-occurrence of an error that was previously fixed.
View deployment details
Rollbar’s Deploys view provides a quick summary of all your recent deploys, including who triggered the deploy and what changes were included. This information can speed up root cause analysis when a recent change led to a spike in errors.
Visualize deploys and errors across time
When deploys are tracked in Rollbar, they will appear in project and error-level timelines that show error frequency across the last few minutes, hours, and days.
With deploys displayed on these charts, you can quickly confirm if a particular deploy caused a spike in errors.
Track Rollbar errors with Bitbucket issues (JIRA too)
Production apps often have more errors than developers can fix immediately. To ensure that nothing slips through the cracks, Rollbar errors can be linked to Bitbucket or JIRA issues.
Issues in Bitbucket and JIRA can be automatically or manually created from Rollbar, or a Rollbar error can be linked to existing issues. When Rollbar errors are resolved or reopened, the corresponding Bitbucket or JIRA issue is updated.
For teams using JIRA Cloud, the Rollbar for JIRA add-on surfaces real-time error frequency data in JIRA and also updates Rollbar error status when JIRA issues are updated for complete 2-way status sync.
See Rollbar in action with Hipchat, Bitbucket and JIRA
Rollbar integrates with Hipchat, Bitbucket, and JIRA so developers can get notified, investigate, and keep track of critical production errors with the tools they use every day. Check out the Rollbar + Atlassian page to watch a quick video and sign up for a 14-day free trial.
By Claire Maynard on January 3, 2017
If you didn’t hear it already, Bitbucket recently announced Pipelines which lets your team automate the integration and delivery process. Automation in software development is becoming increasingly important. Automation saves you time because you have less manual work and it reduces risk by giving you a consistent and repeatable process for all of your team’s code. Ultimately, you spend less time putting out fires and more time releasing quality code, faster.
While in most cases, your team will want to use automation to trigger builds when branches are pushed, there are times when you may want to add a manual step to your process, such as with longer-running builds or triggering a release manually.
That’s why we’ve added manual pipelines.
Trigger builds manually
Just add a custom pipeline to your bitbucket-pipelines.yml and you’ll be able to trigger it for a commit in Bitbucket.
Trigger builds with tags
Many of those already using Pipelines have asked for this, and we listened! In addition to letting you set up manual pipelines we’ve also introduced an additional way to trigger your builds — with tags.
You can now trigger your builds with tags in your Git repository (and bookmarks for Mercurial repositories). While your usual development workflow may mean pushing branches, your team might use tags to a commit for release. For example, configure a pipeline that deploys on tags then tag your commit to deploy it. Additionally, the name of the tag being built will be available as an environment variable as <$BITBUCKET_TAG>.
- npm install
- npm test
- npm install
- npm test
- npm publish ./
Check out our guide on how to trigger builds with tags.
Try Bitbucket Pipelines
If you’re ready to get started with Bitbucket Pipelines, sign up for a Bitbucket cloud account.
If you’re already using Pipelines, you can learn how to set up manual-triggered and tag-triggered builds here. Have feedback for us on these features? Tell us what you think by tweeting us @Bitbucket.
The Bitbucket Pipelines Team
By Amber Frauenholtz on December 13, 2016
2016 has certainly been a year for the books. All year long the Bitbucket Server & Data Center team has been improving Bitbucket and . You told us that modern software developers require tools that are reliable, let move fast, and build with high quality. We took your feedback to heart and built features that enable collaborative development without sacrificing speed or performance.
One hundred customer suggestions resolved, 100+ Bitbucket T-shirts printed, and thousands of cups of coffee consumed is one way to describe 2016 for Bitbucket Server, but that only scratches the surface.
To celebrate the launch of our final release in 2016, we thought it only fitting to review our development stats and favorite new features of the year.
Bitbucket Server team landscape
Our Bitbucket team was busy coding, designing, and documenting throughout the year. Here’s a at some of our most interesting stats.
Favorite new features
A year in review post wouldn’t be complete without a look at our most memorable features. From boosting performance for geographically dispersed teams to creating an unrivaled pull request workflow we did something for everyone.
- Sped up clone & fetch times for remote teams with smart mirroring for Bitbucket Data Center
- Added support for storing large binary assets with Git LFS
- Saved developers time by automatically transitioning JIRA issues with smart commits
Pull request progress became easier to track with reviewer status
Resolved one of our most requested feature suggestions with code search across projects and repositories
Streamlined the code review process with iterative reviews
The end of a busy year
In the software development world, every new year brings about new technologies and ways of working. Since Bitbucket Server’s beginning in 2012 it has been our privilege to find creative and thoughtful ways to make these changes available to you. Bitbucket Server 4.12, available today, caps off a year full of releases that do just that – bring modern software development to professional teams.
As 2016 comes to an end, we’d like to send a big thank you to all of our customers. You are the reason we get to do what we love every single day.
Start the new year off right and upgrade to Bitbucket Server 4.12 today.
Try Bitbucket Server 4.12
By Ben Echols on December 5, 2016
Your master branch represents the code that you will ship to your customers, and should be protected at all costs. No one intends to ship a bug to a customer on purpose, so having a mechanism in place to catch these subtle bugs is essential to a development team. Code review has been around in some form since the dawn of version control to help keep a close eye on the master branch and ensure code quality is high.
Pull requests in particular provide a way to do peer code reviews and merges as part of a branch-based development workflow. As teams grow sometimes you need to take pull requests a step further to really make sure code is ready to be merged in to the family jewel: the master branch.
Merge Checks in Bitbucket Cloud
That’s why we added merge checks to Bitbucket: they make it easy to ensure that every Pull Request is fully vetted before it gets merged. This gives teams the flexibility to:
- Require a certain number of approvers: get at least 1 additional set of eyes on any change before it is merged. (On the Bitbucket Cloud team, we require 2 approvals for every Pull Request.)
- Require a certain number of successful builds: Peer reviews are great but take that extra step and make sure the builds are passing pre-merge. Everyone says don’t break the build, but do you mean it?
- Require all tasks to be completed: those tasks are there for a reason. Make sure all the feedback reviewers leave gets addressed, instead of promises to fix it later.
- Reset approvals when the source branch of a pull request is modified: along with required approvers, this guarantees that no change goes unreviewed. This can be overkill for some branches, where reviewers can approve a PR while trusting the author to make some small tweaks, but it’s great for making sure nothing slips into a critical branch (typos in the release branch, anyone?).
Atlassian is a public company, so the Bitbucket team uses these checks as part of our compliance controls to prevent unauthorized changes to our code, and we know many teams have similar requirements. We also know that having an entire repository locked down can be frustrating, which is why we made merge checks totally configurable at the branch level. Production code can be protected and thoroughly reviewed but until it’s ready, you can still iterate quickly on features in dev and staging, all in the same repository.
Try Merge Checks
Merge checks are a feature in Bitbucket Cloud’s Premium plan which has features for teams that require granular admin controls, security and auditing. All features in Bitbucket Cloud’s premium plan are in a free trial until early 2017 when the plan will be $5/user/month.If you’re ready to get started, sign up for a Bitbucket Cloud account.
If you’re already using Bitbucket Cloud, you can add merge checks from your repository settings menu, under the branch permissions section.
Get started for free
Have more specific questions about this post? Reach out to us on Twitter to get the information you need
By Szilard Szasz-Toth on November 30, 2016
Modern software development teams are increasingly distributed around the globe and expect to work fast from anywhere in the world. However, the desire for development speed can sometimes be blocked by factors out of your control – like waiting hours when cloning because you’re in a remote location and have a slow internet connection. This is a common occurrence if your team is working with lots of historical information in your repository, is storing large binary files or is using monolithic repos.
Reduce clone times with Smart Mirroring
We developed Smart Mirroring for Bitbucket Cloud with these distributed teams in mind who want to drastically reduce clone times. With Smart Mirroring, you can:
Smart mirroring can be set up in 4 steps, and less than 10 minutes. You install the mirror locally, set up security with SSL, start and connect the mirror to Bitbucket Cloud, select what you want to mirror, then sit back and enjoy the speed. Below is a mirror in action, increasing speed by 1.5x:
Smart Mirroring is a feature in Bitbucket Cloud’s Premium plan which has features for teams that require granular admin controls, security and auditing. All features in Bitbucket Cloud’s premium plan are in a free trial until early 2017 when the plan will cost $5/user/month. If you’re ready to start mirroring in a free trial, sign up for a Bitbucket Cloud account.
If you’re already using Bitbucket Cloud, learn how to set up and evaluate a Smart Mirror in less than 10 minutes to see mirroring in action.
Get started for free
Have more specific questions about this post? Reach out to us on Twitter to get the information you need
By Amber Frauenholtz on November 15, 2016
Raise your hand if you remember the days of in-person code reviews. Whole afternoons spent checking out changes from SVN, running them locally, and making notes of areas that could be improved. Then spending another hour or two in a room with your team discussing suggestions live. Once changes were incorporated the whole process began again until it was finally time to merge. Ah merging… never fun and often times a total nightmare.
Quality time with the team is great, but we sure are glad those days are over. Thanks to the rise of distributed version control (DVCS), like , the process to garner peer feedback has vastly improved. Git’s ability to branch and merge easily has made it possible to review smaller sets of changes more often. This type of code review is based on a concept known as a to discuss proposed changes to your codebase before they’re merged into shared branches (
The popularity of Git and pull requests have been with no signs of slowing down. The benefits of – higher quality code, shared team knowledge, shared sense of ownership – and flexible workflows in Git have lured teams of all sizes. Amadeus, , employs over developers. Since they made the switch from SVN to Git three years pull requests have become an invaluable tool to protect against poor quality code.
“At Amadeus Bitbucket supports + pull requests a day and it’s growing. Pull requests are at the core of how we want our developers to work for higher quality and faster time to market.” – Frederic Ros, Head of Development Efficiency.
Selecting a Git management tool
With development speed and code quality at stake, it’s no surprise that pull requests have become a key selling point for Git management tools. Of course other factors are at play – l – but when it comes to developer productivity it’s the pull request experience that will set one tool apart from the others. They are the best way ensure you’re releasing the highest quality code possible.
we have found that pull requests work best when 5 key pieces of functionality are in place.
1. Assigned reviewers
In their most basic form, pull requests are simply a request to merge changes into a destination branch or fork. Once you introduce the idea of adding reviewers, they become much more than that – a forum for open discussion around code. When you’re looking at a tool to manage your Git repositories, the ability to explicitly add your team members as How else will your team know they need to review your changes?
we make the process even smoother by giving you the option to set up default reviewers for specific types of branches (i.e. feature, hotfix, or bugfix). You also have the ability to use Marketplace add-ons for additional functionality,
What would a good code review be without the comments? Capturing feedback in-context gives pull request authors a reference point for enhancements. Reviewers can make suggestions for changes or congratulate their team member on a brilliant piece of logic.
In Bitbucket Server you have the option to leave : on the entire pull request, commit by commit, on a particular file, or on specific lines of code in a file. Every developer has their preferred way to read and review code, so your tool should cater to everyone.
Pro tip: Need a second opinion on a specific section of code? In Bitbucket Server, you can use an @mention on a particular line to bring in a busy specialist (e.g. front-end ninja, performance engineer, security expert) to review something in particular without saddling them with the whole review.
3. Iterative review
Pull requests create a feedback loop – you write some code, your team reviews, you incorporate changes, your team reviews and approves them, you merge, and then you’re done. If your Git management tool doesn’t provide a mechanism to capture reviewer status or review iterations, how are you supposed to keep track?
In Bitbucket Server, we solve this problem by providing status buttons for reviewers (i.e. if the author needs to make changes you can click “Needs Work”). Once changes have been incorporated, o need to hunt through files for changes or re-review old code. If your team cares about spending their time wisely, then iterative review is a Git tool must-have.
4. Workflow flexibility
The creation of a development workflow involves a lot of factors. For example: Do you work in a highly regulated industry? Who should have access to your codebase? What types of quality checks do you need? The list goes on. This is why workflow flexibility is so important; no two development teams are exactly alike.
In Bitbucket Server we give you the freedom to pick how a pull request is merged (available merge strategies include merge commit, fast forward only, and squash) and when it is merged with merge checks (e.g. only allow merges if there are 2 approvals and a passing build). No other Git tool rivals the flexibility found in Bitbucket Server. We give you the power to decide how you want to work, not the other way around.
Finally, before purchasing a brand new Git management tool, consider how it will fit in with the rest of your toolchain. Development is way more fun when you don’t have to jump between tools to report on pull request status. With thoughtful integrations like Bitbucket Server handles the overhead for you. Save time and keep everyone up to date with . Atlassian provides a Marketplace full of additional integrations and functionality through add-ons
reduces the amount of bugs in your code. It’s a safety net for developers, a way to ensure you’re putting out the highest quality code you can. At the end of the day, your customers only care if your product works for them or not. That’s why code review and pull requests are so important when selecting a Git management tool. This process cannot fail you.
By choosing Bitbucket Server, you’re choosing the best pull request experience for your team. Assigned reviewers, in-context comments, iterative review, workflow flexibility, and first-class JIRA integration are all built in. We have made pull requests a priority, and folks like Amadeus, Splunk, and our third party Solution Partners have noticed.
“Pull requests have become non-negotiable part of the developer workflow. Bitbucket Server’s pull requests are one of the top reasons our customers switch to Bitbucket” – Zubin Irani, CEO cPrime Inc.
Make pull requests your priority and try Bitbucket Server today!
Try Bitbucket Server
Interested in Bitbucket Cloud pull requests? Learn more here.
By Justine Davis on November 14, 2016
When starting to develop an idea into a game, there are a lot of things to consider: picking the right game engine, setting up a dev environment, getting early feedback, the list goes on. With all of this going on the last thing you want is to have to fiddle around with your tooling, or even worse, forget to backup your code entirely.
Indie game development often means working long hours on limited funds, and doing multiple jobs in parallel to pursue your dreams. The need for speed is essential. the correct version control system comes in – it should be somewhat “invisible”. Perforce has become synonymous with gaming development, because there used to be a perception that Git did not play nice with large files. With the addition of Git Large File Storage (LFS), Git is poised to be the preferred version control of choice for gaming development, just as it is for almost every other industry. But why?
Perforce vs Git
With Perforce, you have to be connected to the central server to see a history of changes, creating a bottleneck. Perforce also maintains a branching record on a per-file basis which creates a lot of metadata, making branching very expensive and restrictive. With Git, you can work from home or the beach without having to be connected to a central server and carry the full history of your code repository with you. This means Git is lightning fast compared to Perforce and is conducive to modern workflows. Making a branch for a new feature with Git’s branching model is simple, inexpensive, and built for modern software development best practices like CI/CD to ensure your code is always production ready.
Git beats out Perforce in cost and speed but there is one other major player when it comes to choosing a version control system for gaming: versioning large files- which has been solved.
Track all your files in one place with Git LFS
Before Git LFS, game developers who wanted to use Git ran into problems because Git repositories usually have size limits to ensure operations run performant as a repo grows. As they would add and change large binaries in Git, their repos would quickly bloat in size and become very slow. Hacks were created to work around these limitations like tracking large assets outside of Git in local storage systems or cloud storage providers. This required the team to manually sync and communicate all changes to keep code working.
Now with Git LFS, game developers can version large files alongside their source code. Git LFS keeps your large files in parallel storage, and only lightweight references are stored making your repos smaller and faster. The next time your team clones a repo with files stored in Git LFS, only the references and relevant large files that are part of your checked out revision will get downloaded, not the entire change history. And with our launch of LFS general availability this October, Bitbucket Cloud has upped the game when it comes to Git LFS by adding the following features:
- Embedded media viewer: collaborate on 80+ file types of any size and preview LFS files inside Bitbucket
- Resumable up/downloads: Stop worrying about transferring really large files and continue where you left off
- Increased parallelism of files with chunking: upload chunks of the same file in parallel for faster up/download times
- De-duplication on file uploads: File uploads are chunked, so only the changed chunks will get re-uploaded
To start using Git LFS, follow these easy steps or to learn everything you could possibly want to know about LFS, read this in depth guide.
Why Bitbucket for game development?
Depending on the kind of game you’re making, costs can quickly add up. You’ve got decisions to make about tools, technology, even music.
We also know that the faster you can get your game out in the world, the faster your user base grows and money starts coming in. In October we announced the general availability of Bitbucket Pipelines, our continuous delivery service built right within Bitbucket Cloud that gives you end-to-end visibility from coding to deployment so you can automate many of the tasks associated with building, testing, and deploying services. The best part? included in our 5 user free tier.
Bitbucket integrates nicely with the tools you need to create your game. We offer best in class JIRA integration for full development traceability across your issues. If you are looking to use Unity for your game engine, you can get set up with Bitbucket and Unity in 7 easy steps.
Free marketing for your game
Choosing the right version control system and Git solution that can scale with your game is essential for your games’ success. Check out our Bitbucket for gaming resource for more ammo on making the switch from Perforce to Git, to get everything you could possibly want to know about Git LFS, or get some free marketing and get featured on our page by submitting any games you’ve already #BuiltwithBitbucket to us on Twitter with the hashtag (there could be an extra surprise in store for you if you do, ).
Get started for free
Have more specific questions about this post? Reach out to us on Twitter to get the information you need
By Amber Frauenholtz on November 8, 2016
There is no denying that peer to peer feedback decreases the amount of bugs, shares knowledge across the team, and creates a sense of shared ownership of every feature. This is why we’ve been working hard to make Bitbucket Server’s pull requests (a.k.a lightweight code reviews) a quick and painless part of your day. Today we’re introducing iterative reviews in Bitbucket Server 4.11, allowing your team to discuss changes to code in the context of a single pull request.
See what’s changed since your last review
Let’s be honest, everyone knows pull requests are valuable but sometimes they can become a bit of a drag. We’ve all been there – tagged as a reviewer on a monster pull request that updates every time you refill your coffee. So much time is wasted looking for the newest changes. You ask yourself questions like, “Did I already review this piece?”, or “Have the comments left by so and so been addressed?” Thanks to iterative review you now have the answers.
When a pull request is updated Bitbucket Server will show you exactly what has changed since you last reviewed it. No more hunting through files for edits or re-reviewing code you’ve already seen. Upon returning to an updated review Bitbucket will automatically display the ‘number of since your last review’ in the request scope. This will allow you to comment only on those newly added commits.
Pro tip: If you’re not ready to approve a pull request, click the “Needs Work” status indicator. When you come back, Bitbucket Server will show you only the changes made since then. Still not happy? Add comments on the new unreviewed changes diff and the author will be notified of your feedback just like before.
Merge your request with confidence
On the we’ve also been the author of those monster pull requests. You know, the ones containing code with the potential to bring down your entire product. You’ve done your best to ensure there are minimal bugs and green builds, but without your team giving the thumbs up merging can be stressful.
This is why pull requests are great… that is until you start to incorporate changes and your team must re-review. Questions like, “Did everyone see your fix for that big issue?”, or “Is my pull request ready to merge?” run through your head. Relieve some stress and have peace of mind knowing the team has reviewed all of your changes thanks to iterative review.
Iterative reviews are a pull request game changer. As a reviewer, regain time back to code by avoiding playing the “Have I Already Reviewed This?” game. And as an author, merge your changes with confidence knowing every modification has been reviewed. Upgrade your team’s pull request workflow and download Bitbucket Server 4.11 today!
Try Bitbucket Server 4.11
But wait… there’s more! Besides iterative review, Bitbucket Server 4.11 is chock-full of other goodies including:
- Adaptive throttling of SCM hosting operations: A new throttling approach for SCM hosting operations that adapts to the stress the machine is under.
- VPAT Documentation: Bitbucket Server has been reviewed in accordance to Section 508 accessibility standards.
- Postgres 9.6 Support
- + bugs resolved: That’s right, 30+ bugs resolved!
Read more in our release notes.
By Tim Pettersen on October 26, 2016
Alongside your professional “day job” Bitbucket account, you may just have a personal Bitbucket account where you’re building silent iPhone 7 games, hacking on the first killer VR app, or training TensorFlow to write one for you. To access both accounts from one computer, you’ve either had to use HTTPS for repositories belonging to your second account, or mangle your SSH config in order to provide the right key for the right clone. All whilst wondering why your repository’s SSH URL is prefixed with the seemingly redundant firstname.lastname@example.org or email@example.com.
Moonlighters, I have good news for you! You can now prefix your repository URL with your Bitbucket username to easily use different SSH keys with different accounts. Simply clone from firstname.lastname@example.org and Bitbucket will use the correct key proffered by your SSH agent.
To update a local repository to specify your username in the clone URL:
# determine your Git clone URL
$ git remote -v
origin email@example.com:kannonboy/flappy-bird-vr.git (fetch)
origin firstname.lastname@example.org:kannonboy/flappy-bird-vr.git (push)
# replace git@ with your-username@
$ git remote set-url origin email@example.com/kannonboy/flappy-bird-vr.git
If you haven’t already, you can easily generate a second SSH key for your alternate account:
# generate and add a new SSH key
$ ssh-keygen -f ~/.ssh/your-username
$ ssh-add ~/.ssh/your-username
(You’ll also need to add the contents of ~/.ssh/your-username.pub as a new Bitbucket SSH key.)
ssh-add adds the key to your local SSH agent, which Git and Mercurial will use automatically when interacting with a remote repository over SSH.
During key exchange, your SSH agent offers all the keys that may be appropriate for a particular host. Using git@ as a prefix means Bitbucket doesn’t know which user you’re attempting to authenticate as – so it accepts the first key that it recognizes. If this key belongs to your professional account, and you’re attempting to access a personal repository (or vice versa), you’re outta luck. Using your-username@ as a prefix allows Bitbucket to filter down which SSH keys should be accepted for a particular request.
If you have but a single Bitbucket account – no need to do anything. For backwards compatibility (and supporting things like deployment keys) git@ and hg@ will continue to work for the foreseeable future.
By Kelvin Yap on October 25, 2016
The fastest growing companies in the world today aren’t product companies, they’re . Where we used to buy cars, we now hail a ride from a ridesharing app, and where we used to buy physical music, we now stream online. Agile and DevOps methodologies are increasingly popular today as software development teams strive to improve their velocity to keep up with this demand, and these teams are breaking down silos in order for their various engineering, support, and IT orgs to operate better together.
Continuous Delivery in particular is allowing teams to automate many of the tasks associated with building, testing, and deploying their services. This automation allows teams to meet customer demand for frequent releases while improving the quality of their services, and we’re proud to announce that Bitbucket Pipelines is now generally available to help all teams build, test, and deploy using continuous delivery, all within Bitbucket Cloud.
Configuration as code
If you missed the launch of the beta earlier this year, Bitbucket Pipelines is built right within Bitbucket Cloud, giving you end-to-end visibility from coding to deployment. With Bitbucket Pipelines there’s no CI server to setup, user management to configure, or repositories to synchronize. And where your build configuration files might be hosted separately from your code, Pipelines keeps everything together in Bitbucket. Better still, your configuration files are managed and versioned, allowing for your team to view, edit, and review to ensure quality like the rest of your code.
Gone are the days of having to switch between different systems to work out the status of your builds or why they’ve failed – Pipelines brings the status of builds into your repository. You can see the status of your branches and commits everywhere in Bitbucket, giving you crucial visibility on the status of your builds when you branch and before you merge.
I to get started too – all you need to do is commit a single configuration file into your repository and you’re good to go. Your configuration can be as simple or as complex as you need and with Pipelines utilizing Docker containers, you have the flexibility to choose from a wide variety of languages.
Estimating capacity for your builds is a fine balancing act. Underestimate and you risk builds queuing up, resulting in idle time for your developers; overestimate and you’re wasting money on extra capacity. Bitbucket Pipelines scales instantly, helping you avoid queues by scaling up on demand when you need it. And with Pipelines you don’t have to pay for idle time, saving you money .
Whether you want to deploy, test, monitor, analyze code, or store artifacts, complete any workflow with the tool of your choice by bringing your favorite services to Bitbucket Pipelines. We’re working with many industry leaders to ensure there’s continued support for the tools and technologies your team needs to build and ship software. integrations include AWS, Google, Microsoft, npm, Puppet, Rollbar, Sauce Labs, Sentry, SourceClear, TestFairy, and many more. Check out our integrations page for the full list of integrations.
Pay for what you use
Best of all, Bitbucket Pipelines utilizes a unique pay-as-you-go model for pricing. Never pay for containers and getting charged for the days, weeks, or even months when a given repository is idle; get started with continuous delivery for as little as 1 . Based use during the beta, that’s less than a cup of coffee a month for each !
With Bitbucket Pipelines we want to help all teams deliver better software faster, and we’re excited about the future of Continuous Delivery within Bitbucket. Try Bitbucket Pipelines and accelerate your team’s releases today.
Sign up for Bitbucket