By Tim Pettersen on March 1, 2017
The Bitbucket team are excited to announce a brand new integration with Unity Cloud Build, just in time for GDC 2017!
Traditionally, game builds are compiled, tested, and packaged by developers via their IDE or another tool provided by the game engine SDK. This is sub-optimal as it wastes developer time and resources, excludes non-technical contributors from building the game, and requires builds to be uploaded and hosted somewhere to share with other team members. The situation is even worse if you target multiple platforms with your game, as you’ll need to create separate builds for each platform.
Fortunately, Unity Cloud Build provides automated builds and continuous integration for your Unity projects hosted on Bitbucket. Bitbucket’s new Unity Cloud Build integration improves this experience by allowing you to jump quickly from your source code in Bitbucket to a built, playable version of your game or app.
Once the integration is enabled, Unity build logs and artifacts are posted to Bitbucket as build statuses, so you can jump from your source code in Bitbucket to a playable version of that same code with a single click. The integration automatically creates a sharable link for each game artifact, allowing any team member to access builds for the latest version or historical versions of their game – without having to wait for a developer to cut a build for them.
Your project, your platforms
Unity Cloud Build supports a range of target platforms including Android and iOS games and apps, desktop games for Windows, macOS, and Linux, and WebGL builds for the web! In fact, for WebGL builds, you can click straight from your code in Bitbucket to an interactive web player and play your game without having to download a build yourself.
Unity Cloud Build platforms, February 2017
Unity Cloud Build statuses will appear against their corresponding commits, branches, and pull requests in the Bitbucket UI. This makes it simple to:
- get the very latest version of your project by clicking the build at the tip of your master branch;
- play code changes while you review them, by clicking on the latest pull request build; or
- check whether an earlier version of your game exhibits a particular bug, by clicking a build on a historical commit!
If a build happens to fail, no game artifacts are generated, but a handy link to the build logs will be displayed instead so you can quickly debug the failure and get your project building again. Speaking of failed builds, Unity Cloud Build statuses are fully integrated with Bitbucket’s merge checks which can be optionally enabled to prevent failing code from being merged into master, keeping your game buildable at all times.
We’re at GDC 2017!
The Bitbucket and SourceTree team will be representing at GDC in force! If you want to catch a demo of the Unity Cloud Build integration, score some Atlassian swag, or have any questions about our game development tools: come and find us at Booth #336, South Hall Zone 2.
I’ll also be giving a talk – Collaborating on Unity Projects with Git – at 4pm in Room 3014, West Hall. It’ll feature the new Unity Cloud Build integration, alongside some tips for versioning Unity projects in Git, handling large assets with Git LFS, and Git workflows for game dev teams. Looking forward to seeing you there!
Get started, it’s free
By Alastair Wilkes on February 28, 2017
We live in an age where data breaches are very . In the last three years have experienced massive – yet shows that most companies are still not fully security threats and haven’t taken necessary to overhaul their security measures. No matter how much focus is put on , it’s the end user that is ultimately the weakest link and can be vulnerable to password hacks.
To avoid this, it’s more important than ever that you aren’t just securing your account with a password, but also taking measures like two-step verification to keep your private content on Bitbucket, well… . In addition to two-step verification, Bitbucket is taking security a step further for teams who store their source code in Bitbucket Cloud and desire additional security: team admins can require their teams to enable two-step verification limit access to private code by IP address. Let’s take a deeper look at how admins can benefit from IP whitelisting and required 2-step verification.
Introducing IP whitelisting for your private
With IP whitelisting enabled, users will only be able to interact (view, push, clone, etc.) with your account’s private content if they are accessing Bitbucket from an IP address you have selected and know is safe. If a user tries to access any of your team’s repositories, issue trackers, wikis, snippets or team settings from an un-whitelisted IP, they’ll receive an error. This helps prevent unwanted third parties from accessing your account even if they have acquired a team member’s email address and password.
When digging into the use cases and needs of these teams, we found some common themes for how this feature would be used:
- Security controls on devices – admins often want to make sure the desired security controls are in place on a user’s device before the user can even get network access to private content
- VPN Server – lock down your VPN server for remote employees to access private content via authentication from their device
“For Limpid Logic customers, remote access and IP whitelisting are sometimes a legal requirement, especially for clients in highly regulated industries such as finance and healthcare. Our work often deals with sensitive intellectual property that requires limited geographic access to repos from a few specific IPs,” said Bachir El Khoury, Managing Director at Limpid Logic. “IP whitelisting is exactly what we need within our business and we’re thrilled to see this security feature in Bitbucket.”
IP whitelisting is a feature of Bitbucket’s Premium plan and can be found under the access controls section of your account settings.
Ensure secure access with required two-step verification
Two-step verification (also known as 2FA) ensures your data will continue to be protected even if someone else gets your password. This great for those who have it enabled as an extra security mechanism, but how do you really know if your team is taking advantage of this extra security? Manually following up is always an option for a small team, but what happens when your team grows to 10, 20, or more than 100?
We’re launching required 2-step verification in Bitbucket for these account administrators who require their team to have two-step verification to access private code. When you enable this option for your team, users will need to have two-step verification enabled in order to interact (view, push, clone, etc.) with your account’s private content: repositories, team settings, issue trackers, wikis, and snippets. If a user doesn’t have two-step verification enabled at the time of access, they’ll see instructions on how to enable two-step verification in the UI and continue.
Bitbucket’s Premium plan
of features are available in Bitbucket’s Premium plan, which also includes merge checks, smart mirroring, 1,000 build minutes/month for Bitbucket Pipelines and 10 GB/month of Git Large File Storage (LFS). This plan specifically aims to improve the experience for administrators of teams with lots of users and repos, complex business requirements (as a result of industry standards, etc.) or both, which we’ve found become more prevalent as a team grows.
Try IP whitelisting and required 2-step verification
If you’re ready to enhance your security measures, sign up for a Bitbucket Cloud account. If you are already a Bitbucket customer, further documentation for IP Whitelisting and requiring two-step verification can be found 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.
By Amber Frauenholtz on February 23, 2017
When you hear the terms security and speed, Git repository management may not be the first thing that comes to mind. But for software development teams, these 2 things translate into 1 big thing: productivity. Today we’re releasing Bitbucket Server 4.14 which includes access keys in branch permissions, automatic dashboard updates, and an email notification enhancement.
Keep reading to learn how these features can help your team move faster.
Access keys in branch permissions
Permissions and Git can be a tricky thing; without a tool to enforce access control, anyone can read or write to your repositories. In Bitbucket Server you can give users access to anything – a specific project, a single repository, or just a branch. You can also give permissions to access keys, which allow continuous integration servers and other automated processes to interact with your source code.
Previously, access keys were granted only at the project and repository level, causing some trouble when branch permissions were also applied. The only way around this was to create a user account for your CI server and explicitly grant it branch access like other members of your team.
In Bitbucket Server 4.14, access keys are now applicable at the branch level, thus avoiding extra user creation. Updating repository metadata on restricted branches is as easy selecting an access key in the branch permission’s dialog.
Automatic updates and email reviewer status
Next up, 2 new features that make getting information just a little bit faster. First an update to the personal dashboard – no more refreshing required. When changes are made to your pull requests, i.e. approval or comment, they’ll be reflected automatically on the dashboard. Waiting for your pull requests to be reviewed? Pop open a tab, sit back, relax, and watch the approvals roll in.
Second, an enhancement to pull request email notifications. Pull requests are imperative for ensuring high quality code, which is why we’ve built Bitbucket Server’s pull request experience to cater to teams.
Currently when updates to pull requests occur (i.e. a reviewer changes the status to ‘needs work‘), the subsequent email notification batches this change with many others. To get a good idea of all the activity, you’ll need to open the email and scroll through the updates.
In Bitbucket Server 4.14 you can now get a feel for changes by looking at the reviewer status in the notification header. A new ‘needs work‘ status is a quick indicator that the pull request needs revisiting.
Try Bitbucket Server
For more information on other improvements and bug fixes in Bitbucket Server & Data Center 4.14 check out our release notes.
By Claire Maynard on February 15, 2017
Since Bitbucket Pipelines launched back in October 2016, we’ve heard a tremendous amount of positive feedback and excitement about the new built-in CI/CD . A ton of you about how you’ve configured your Pipelines for use cases. For instance, we were thrilled with James Fairhurst’s blog about getting set up on Bitbucket Pipelines and Laravel and Ozren Lapcevic’s blog on building, testing and deploying Django App with Bitbucket Pipelines. We appreciate your commitment to sharing best practices with the rest of the community – thank you! Keep ’em coming!
Today we’re excited to share some of our own tutorials, including five new Pipelines language guides and four new deployment , making it even easier for you to set up Pipelines.
New Language Guides
New Deployment Guides
We’ve also added several deployment guides if you’re interested in fulfilling the full software development life-cycle with Bitbucket.
We’ll be adding more soon, so make sure to check back! As always, if you have feedback on any of these guides, please tweet us @Bitbucket Pipelines.
Haven’t tried Bitbucket Pipelines yet? Give it try!
Try Bitbucket Pipelines
By Tim Pettersen on February 1, 2017
At this very moment, members of Atlassian’s Bitbucket and SourceTree teams are converging on the city of Brussels, Belgium for the annual Git Merge conference and Git Contributors’ Summit. If you happen to be attending the conference, or are otherwise in the neighborhood, come along to our Beers on Bitbucket meetup on Thursday night to meet some of the developers behind Atlassian’s DVCS tools. In addition to providing (and imbibing) beer, we’ll be hosting a few short tech talks covering various aspects of our Git tools:
Bitbucket Architect Erik van Zijst will discuss our recent proposal to add clonebundle support to Git
- SourceTree Developer Mike Corsaro will give a tech talk on SourceTree’s combined usage of both native git and libgit2
- Bitbucket Developer Tim Pettersen (that’s me) will demo Bitbucket’s new built-in CI/CD service: Bitbucket Pipelines
Registration is free, so sign up here and come along to The Pentalounge, Pentahotel Brussels City Centre on Thursday from 5 – 7.30 to get your Git on.
Sadly the actual Git Merge conference is now sold out, but if you’re coming along keep an eye out for these cheerful Atlassians and bug them for some Bitbucket swag:
Also, make sure you catch my session Git aliases of the Gods! at 3.15pm for a fun and moderately educational look at how to use (and abuse) Git’s aliasing system. Actually it’s a single track conference, so you don’t have a choice ?
But more importantly, we’re excited to rub shoulders with both contributors and enthusiasts of the world’s most popular distributed version control system, and geek out on Git for 48 hours in Belgium.
By Abhin Chhabra on January 31, 2017
Imagine you’re working on a feature. You create a pull request with your changes and get some feedback. You update your pull request by adding another commit that addresses the feedback. Maybe you notice a typo. So you create another commit that fixes the typo. Very soon, your feature branch has a lot going on with all these commits:
So you get your PR approvals and you merge. But looking through your repository’s history, you notice that it looks busy. A lot of these commits don’t actually add any value to your repo’s history. They clutter up the blame, make bisects take longer and generally make the history hard to navigate.
Squash your commits in Bitbucket Cloud
You could always squash commits via the command line using “git merge –squash” but this is just another time consuming step, and it would be a lot easier to have it done for you from Bitbucket. Today we’re launching the ability for Git users to squash commits in feature branches when merging pull requests. Combining these commits will provide a clean, easy-to-follow history for your repo. This new merge strategy can be found when a pull request:
Merge commit (–no-ff) will keep all of your commits from your feature branch, while Squash (–squash) is the new option that will allow you to combine your commits and clean up your repo.
on squashing commits in Mercurial
This feature rollout applies only to Git and not Mercurial… yet. Squash requires exchange of obsolescence markers – part of the evolve extension – so we’re working with Mercurial’s maintainers to get evolve bundled in core Mercurial, as well as adding support for it in Bitbucket. For developers already using the evolve extension, we hope to have a beta for squashing in Mercurial available soon.
In order to help make features like this accessible to the community in the future, including through further development of the Mercurial platform, Bitbucket is making a charitable donation to the Software Freedom Conservancy. We’re proud to support the Software Freedom Conservancy and promote the development of platforms like Mercurial, and encourage you to keep a look out for advancements to come.
Next time you want to merge a pull request, try out the squash merge option and tell us what you think on Twitter.
If you’re new to Bitbucket, sign up for an account, import some code, add your team mates and have them review your code via a pull request. When you are ready to merge their feedback, you will find the new squash merge strategy.
Looking for more in depth information on this new feature? More information on squash merges can be found 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. Looking for squash merges in Bitbucket Server? Merge strategies are available in Bitbucket Server 4.9.
By Amber Frauenholtz on January 26, 2017
You’ve probably heard the word “simplify” floating around a lot this time of year. People are setting New Year’s resolutions, cutting the clutter, and generally, trying to do more with greater efficiency and focus. On the Bitbucket team, we’re trying to simplify too, which is why our first release of 2017 includes several new features to make your day to day a little easier.
Edit files in-browser
Fixing typos, editing README files, and making other small changes can require a fairly large amount of steps relative to the size of the change. First, you must clone the repository locally, then make your change, next push back up to Bitbucket, and finally create a pull request (if needed). Before you know it, a quick spelling change has taken 5 or 10 minutes. And for those who aren’t as prepared to make changes locally, for example a doc writer who hasn’t installed Git, this can be quite daunting.
In Bitbucket Server and Data Center 4.13, we’ve simplified the process by letting you edit files inside of Bitbucket. To help make your change, the editor pre-selects a syntax based on filetype, lets you add a commit message, and even offers the option to create a pull request on push. With no need to do anything locally, simple changes can be applied much more quickly.
Easily find related JIRA Software issues
The past few years we’ve made huge enhancements to our JIRA Software and Bitbucket integration. Features like smart commits, embedded issue information, and the development panel in JIRA improve visibility and save time. As part of our continued focus on this integration, today we’re releasing a small but powerful improvement to JIRA issue integration. Throughout the Bitbucket UI JIRA issue keys have been modified to become hyperlinks to JIRA, making it easier to locate and dig into related issues. Keys are now clickable in commit messages, pull request titles, and in branch names.
Built-in SAML 2.0 support in Bitbucket Data Center
For admins looking to simplify user management in Bitbucket Data Center, SAML 2.0 single sign-on support is now available out of the box. SAML support integrates into your existing infrastructure, providing developers a more secure and hassle free way to log in. Having only one username/password to maintain means quicker access to tools and less password reset requests for admins.
We support a large list of popular identity management providers including Okta, OneLogin, Azure, Active Directory (ADFS), Bitium and PingOne.
Upgrade to Bitbucket Server 4.13
No matter what your New Year’s resolution is, we can all use a bit more simplification in our lives. Small improvements lead to big gains. In this case, less time switching between tools, looking for links, or fighting with passwords means more time spent on whatever is important to you.
Upgrade to Bitbucket Server 4.13
But wait, that’s not all! In Bitbucket Server 4.13 we identified areas to use less memory by caching template rendering. With this improvement, 4.13 uses less memory than any other 4.X version of Bitbucket. For a list of other improvements and bug fixes check out our 4.13 release notes.
By Amber Van Hecke on January 20, 2017
Git tags have become essential to a Git workflow to mark specific points in your Git history (like referencing a specific version of a project by tagging a commit for your release). They reduce complexity, clean up your branch workflow, and are a way to mark exact versions of commits. If you change versions a lot, they are a life saver instead of just using branches, which commonly leaves you with lots of rarely used branches.
Add tags from the UI vs the command line
Bitbucket users have asked us how they can cut out this back and forth and tag commits directly from Bitbucket Cloud’s UI, and today we’re launching this capability to add git tags and regular mercurial tags directly to commits from the UI. The name of the tag, date/time, and author can be applied to any commit.
If you’re reading this thinking “why would someone tag a commit from the UI? The command line works just fine for me.” Lets look at where you can save time and find commits that need tagging in Bitbucket without switching over to the command line:
- Branches page: Quickly check that all features scheduled for release have been merged into your main branch, before creating your tag.
- Commit’s build status: Double-check the build status of your commit. If there’s a failing build, you might want to push some fixes before creating your tag!
Add tags from Bitbucket’s UI
To add a tag, navigate to a commit in your repository and click on the commit in need of a tag. In the details pane, on the right side of the commit view, you can see ‘current tags’ and ‘create tag’. Once ‘create tag’ is selected, the author and timestamp will automatically be recorded.
In the future we will be expanding tagging from the UI with the ability to add custom messages to compliment any annotated git tag applied in the UI. If you are looking for lightweight tags, they can still be added via our API but are not currently available in the UI.
Try tagging commits
If you already use Bitbucket, start saving time with this new feature and start tagging (allthethings). If you’re new to Bitbucket, sign up for a Bitbucket Cloud account, create a repo and make a commit to take it for a spin. If you get stuck, more in depth tagging documentation is available 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
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