Bitbucket team here with a quick update on how we are managing the Bitbucket blog. Starting Friday, October 7th, we will be turning off commenting on the blog.
It’s not that we don’t want to talk to you – we do! We noticed that sometimes blog comments go unanswered for weeks because a comment get posted on a really old blog post. We want to make sure that you are able to get answers to the comments and questions you have on the right channels and by the right people. Here are the places for you to chat with us on anything from product questions, support requests, reporting bugs, and requesting features:
For any technical issues, please visit our support center.
Feature requests and bug reporting
If you would like to request a new feature or file a bug, please visit our public issue tracker. Here you can see what other Bitbucket customers have requested, follow requests and issues, and even create a new one yourself.
Have any open questions about how to use Bitbucket, Git, or integrate with another product like Microsoft Azure? Visit Atlassian Answers where you will find questions submitted and answered by the user community, ecosystem developers, and Bitbucket staff.
Thank you for reading our blog, and for all the feedback you’ve given us over the years. Talk to you soon!
This post is featured in our ebook, “Hello World! A new grad’s guide to coding as a team”– a collection of essays designed to help new programmers succeed in a team setting.
Grab it for yourself, your team, or the new computer science graduate in your life. Even seasoned coders might learn a thing or two.
It’s not quite what I had in mind when growing up, but right now my role title tells me I am a team lead. In the course of my time in this role, I’ve learned that being a team lead is something my fellow developers are interested in doing someday, so I want to share about my experience. This is what I’ve learned in discovering what it means to be a team lead.
I’ll start with the obvious. A team lead is supposed to manage the people on their team. For me, these people are usually developers. Of course, everyone is different and situations arise in a variety of ways, some that I can prepare for or help with and some that I cannot. Over the years I have learned a lot about how to manage people and how to deal with common problems, but the one common denominator is that I don’t always know what to do in 100% of the situations. This is certainly a never-ending learning exercise. It’s an interesting aspect of the role that managing no one person is ever the same. Getting a team of different people to work together, keeping them challenged and motivated, ensuring they are performing, improving, and growing, is all quite interesting and challenging. Seeing teams form to reach their potential and watching individuals progress in their career is what I find most rewarding about my job.
Generally as team lead, I’m also the one managing the projects and making sure they get delivered on time (← why is that bit so hard?!). Delivering the right features, a good user experience, and high quality software on time is damn hard. There are so many equally important projects going on that should have been delivered yesterday. There is never enough time, so you have to constantly prioritise, which often means just saying no.
This picture best describes the situation I often find myself in. Just picture me in the middle of this four way tug-of-war. In front of me is a product manager, who tells me all the lovely, but never-ending list of things we must do. To the left I have a designer showing me designs for the best user experience we could possibly build. To my right is the quality engineer who always seems to be scolding me about our test coverage and quality of code. And of course, behind me are the developers who tell me things are going to take longer than estimated, complain about the amount of code debt we have, and explain how we need to build things better.
Now, I may be slightly exaggerating here, but the truth is, everyone is rightfully doing their job and pulling me in the direction they are supposed to. I just happen to be the person in the middle. The trick is finding the right balance and not falling over, which is quite hard to do. I sometimes worry if I’ll even make anyone happy in this constant game of give and take.
“As a development lead, it’s my job to be pulled in different directions without losing my balance.”
When I’m not embroiled in a game of tug-of-war, some other things I do associated with project management include sprint planning, roadmap planning, people planning, risk mitigation planning, deployment planning and planning for planning (yes, it’s a thing).
Having a bird’s eye view
This overlaps with project management a bit, but I tend to think about it separately since it’s on my mind a lot. As someone not on the ground coding everyday, I am able to take a step back and look at what my team is building more holistically. There is always a constant stream of questions to be asked and decisions to be made, ranging from technical concepts like implementation to other concepts like if the user experience makes sense. A final aspect of this perspective is considering the project dependencies, or how my team is depending on a different team, and how other teams are depending on us.
Wearing different hats
You don’t necessarily have to be a team lead to wear different hats, but it’s absolutely required of me when the Product Manager, Designer, or QA Engineer isn’t available. I don’t claim to do any of these roles particularly well, but I have to learn to think like these people. It is quite common for questions to arise once development has already started, and it’s usually quicker for me to make these small decisions on the spot, which is where putting myself in someone else’s shoes comes in handy.
Conversations and coding
As a team lead, my calendar is full of meetings, which I prefer to call conversations, because that is what they are. Besides my 1-on-1s with the people I manage, my mentors, and my managers, my calendar is usually full with conversations about the software we’re going to build. There is planning to be done, design reviews to go over, technical discussions to be had, and more.
To be honest, I hardly code any more. I code 1-2 hours a week if I’m lucky organised. Most of the team leads I know don’t code much either. Letting go of coding is probably the first thing most devs-who-become-team-leads struggle with. I learned that as team lead it is not my priority to be writing code. In fact, when I do have to code, I’m not as efficient as another developer because I haven’t been following the issue entirely through the workflow. In an attempt to keep up, I try to do random code reviews, set up a dev environment, do a bug fix, or simply pair with whoever is available.
Well, this is my experience being a team lead. Even after a few years, I still find my job stressful, challenging and hard, but for the most part, it is highly rewarding and enjoyable. If one day you find yourself in my position, I hope hearing about my experience will have served you well in the challenges and opportunities you will face.
This post is featured in our ebook, “Hello World! A new grad’s guide to coding as a team”– a collection of essays designed to help new programmers succeed in a team setting.
Grab it for yourself, your team, or the new computer science graduate in your life. Even seasoned coders might learn a thing or two.
Bitbucket Server 4.9 and Bitbucket Data Center 4.9 bring strategy to the forefront of how teams work with their source code. Learn about three new features and how your team and business can set up new strategies to help teams work the way they want to work.
Make disaster recovery part of your business plan
For mission-critical tools like Bitbucket Data Center, disaster recovery (DR) is more than just a feature, it’s a strategy. Why? Because if the main instance goes down (aka a disaster) teams need a tool that allows them to continue working with their data. This is where DR comes into play. It provides Bitbucket Data Center customers the ability to replicate the state of their primary instances to a “cold standby” instance at an offsite location. So if your primary instance goes down, Bitbucket Data Center can cut over to the standby.
A “cold standby” is one example of a disaster recovery plan (DRP) in which the standby Bitbucket instances are cold and the file server, database and Elasticsearch instances are warm, in order for the replication to occur.
Since your standby site contains cloned Bitbucket indexes and a copy of your production database – think critical plugins – your team can quickly get back up and running. At Atlassian we use this model because we have instances in different geographies, so if a primary instance goes down in Sydney we can cut over to the disaster recovery standby instance in San Francisco with minimal downtime.
The addition of DR to Bitbucket Data Center gives teams and businesses the toolset to set up a proactive strategy for when things go wrong, so the prospect of developers sitting around with nothing to do becomes a non-issue. Instead admins and IT can focus on the reason for the downtime – no small feat – while source code work moves forward.
For more details on DR and a reference DR deployment, see our updated documentation.
Choose how your pull requests get merged using merge strategies
While DR and zero downtime backup help teams and business with downtime strategies, Bitbucket Server 4.9 introduces a new feature specific to workflow and code review strategies called merge strategies. Its complement merge checks have been in Bitbucket Server for a while, but merge strategies give users and teams control over how pull requests get merged rather than controlling if a pull request can be merged.
Different teams desire different things when it comes to how they track the history of their repositories. Bitbucket has traditionally been opinionated about applying a merge commit when closing a pull request, but there are good reasons not to always do this. For example, some teams have a different view on what constitutes a clean history and want to use fast forward only or squash merge strategies.
Now a repo admin can define the default merge strategy and specify what alternative strategies are allowed for selection at merge time. That means the person merging each pull request can have full control over strategy used. An example where this can be handy is when you’re using a Gitflow branching model. You might set the default to squash on merge, but allow “no-ff” to be used so that proper merge commit occur between release branches. This detail in a team’s workflow, much like the default reviewers feature, gives teams unique features to work the way they want.
Import repositories from other hosting services
Lastly, starting a new project that requires a migration of repositories in bulk from one product to another or of repos from one server to another server should be frictionless. So instead of writing scripts or importing repos one at a time, the new import repository feature for both Bitbucket Server and Bitbucket Data Center allows for bulk imports to give teams the ability to try out real or demo data.
This is especially important when you’re just getting started with Git and Bitbucket Server, or wanting to pull in code from an existing project from Bitbucket Cloud, Github.com, GitHub Enterprise, or individually from any HTTP-based Git host. It is quick, easy, and gives teams the flexibility to work with data where they want to.
All of the new features released in Bitbucket Server 4.9 and Bitbucket Data Center 4.9 help teams collaborate with strategies in place. The addition of DR to Bitbucket Data Center is important to any team’s daily activities. Your tools are business and/or mission-critical, so work can’t be stopped during a disaster or downtime. And in the world of pull requests, different teams and different repositories may want to use different merge strategies.
The addition of merge strategies to your pull request workflow gives teams the flexibility needed to set up a merge strategy. It is with these types of features that Bitbucket Server and Bitbucket Data Center can help your team and business think about strategy at the team level and up to help teams work better together.
Check out the release notes for more information on these new features and the other improvements we’ve made in 4.9.
In case you missed it
Since Bitbucket 4.5 we’ve continued to improve our pull request experience, add new features, and more. Check out to see what has been added:
- Code search shipped in Bitbucket Server 4.6. You can now search for code directly in the search bar, which includes searching code across all of your projects and repositories. Or you can get more granular to search for code in a specific project or repository. And you have the option to use search operators to get more precise search results and can search for code on the language it’s written in.
- Commit-level review shipped in Bitbucket Server 4.8 to provide per-commit diff views and commenting within pull requests to help reviewers do just that – review individual commits added to a pull request. Highlighting changes at this granular level makes the reviewing experience better for every member on the team and will result in faster pull request turnarounds.
- Default reviewers shipped in Bitbucket Server 4.8 to give teams the option to configure a default set of reviewers that will be pre-populated on the pull request creation form on any given repo. Default reviewers can even be defined by source and target branch, and once it’s set up you can add or remove people from the list as needed.
- Bitbucket Data Center now offers source code collaboration for teams at the 25 user tier. Learn about what features you get when you switch to Bitbucket Data Center including smart mirroring, Git LFS, and more.
- For an entire roll-up of features check out our updated documentation.
February 2017 update: Now 6 million developers and 1 million teams.
A sincere thank you to the 5 million developers, 900,000 teams and countless amazing projects that were developed by our users with Bitbucket over the last year. Everything our users do inspires everything we do – from offering free unlimited private repositories for small teams to building the security features our larger teams need to take their ideas from the first keystroke to production. We strive to make it easy for teams to get started and then scale with Bitbucket as their team grows, and the 5-million developer milestone prompted us to take a look back and reflect on everything that’s happened in the past year.
5 million developers, 900,000 teams
To put it all in context, here’s a little bit of Bitbucket history. Bitbucket launched in 2008 with support for Mercurial repos, followed by Git support in October 2011. Since then, we’ve seen a massive adoption amongst the developer community. Through the help of our users spreading the word and building features that cater to professional teams, we have seen rapid growth of developers and teams in Bitbucket over the last 3 years.
Many of us on the Bitbucket team remember the day we reached 1 million users and how amazing that felt. So needless to say, reaching 5 million blew us away.
We are excited that more and more teams continue to trust us with their source code and build innovative software with Bitbucket.
Some cool stuff is #BuiltwithBitbucket
And let’s not forget all the cool stuff these teams have been building. We believe your day-to-day coding has a bigger impact in the world than you give yourself credit for so we asked our users to tell us what they built over the last year. The responses came in droves: Mobile games, musical scores, apps that help you figure out how many diapers you will need for your child, online education, cancer research… the list goes on.
Atlassian’s mission is to empower teams to advance the world through software so we were both humbled and proud to see what the developer community is contributing to the world. It was incredibly cool to see the use cases we never would have thought of and see that our users are using Bitbucket to make an impact on someone’s day out there with what they are coding.
Keep telling us what you are building using #BuiltwithBitbucket. We absolutely love to hear it and show you off.
Behind the scenes, the Bitbucket Cloud team releases on a weekly basis to get new features to our users and solve some common needs: code review, strong integrations, an easy to use UI, security and more. Here are a selection of the most popular features we released over the last year:
- Bitbucket Pipelines Beta: a continuous delivery service built right within Bitbucket Cloud giving you end-to-end visibility from coding to deployment.
- Git Large File Storage (LFS) Beta: improves the handling of large assets so it is easier for your software team to collaborate on not just source code, but rich media and large data with Git.
- Deploy from Bitbucket with AWS, Azure or Digital Ocean: You can deploy to your public cloud from within Bitbucket’s UI, without having to execute scripts or configure deployment plans outside of Bitbucket using Bitbucket Connect add-ons (totaling 54 add-ons and growing)
- Build status API: Save time by knowing when your build is passing and when it is safe to merge changes by viewing build status right in Bitbucket’s UI
- Connect Bitbucket to JIRA Software in 30 seconds: We simplified the experience of connecting Bitbucket Cloud to JIRA Cloud, now you can do it in under 30 seconds.
- Pull request focused dashboard: Personalized dashboard that brings pull requests that need your attention to the front and center, making it faster to find the code review you are looking for.
- 2 Factor Authentication (2FA): Secures your account by requiring a second component, in addition to your password, to access your account so your account is safe, even if your password is compromised.
- Universal 2nd Factor (U2F): Emerging standard for 2FA that uses a physical USB key to digitally sign a challenge from a trusted website. You don’t have a time based password, you just press a button on a USB device plugged into your computer to log in to Bitbucket.
We’ve made strides over the past year, but we’re not done yet. This year’s roadmap is shaping up nicely with more updates to improve your workflow. To keep up to date with all the most recent updates or get a more in depth scoop on a specific feature you can follow our latest features page.
That’s a wrap
Thanks again to our amazing developer community – we can’t wait to see what you build with Bitbucket next. If you are new to Bitbucket, you can can sign up for free unlimited private repositories here or if you are already a Bitbucket user, check out what’s new.
Git makes branching easy, which lets your team efficiently tackle all kinds of problems in parallel. You can use the feature branch workflow to safely develop features in isolation from your master branch, or the git-flow workflow to manage support, hotfix, and release branches. However, Git’s flexibility also means it may be easier to make mistakes.
When switching between branches, a developer can easily delete a branch or push changes to the wrong branch, resulting in confusion and wasted time backing out the changes. To avoid this, many teams want to ensure all commits to the master branch go through pull requests, or that only the release manager has access to a deployment branch to prevent bugs. Some companies also use these practices as part of a compliance regime to adhere to SOX, SOC2, or other standards. Today, we are releasing updates to our branch-level access permissions for your projects in Bitbucket Cloud to help you address these development and compliance concerns.
Updates to branch permissions: flexible and powerful
Branch permissions let you lock down critical branches and customize exactly who has access to a branch. Most teams we’ve talked to tend to have one or two branches that need to be restricted, but they don’t want or need to apply the same restrictions to every branch in the repository. The updated branch permission UI makes it easy to:
- Pick a specific branch to restrict, or set restrictions for all branches matching a pattern.
- Limit write access to that branch to a set of users or groups.
- Limit merging to that branch to a set of users or groups.
- Prevent anyone from deleting or rebasing a branch, even if they have write access.
This means you can lock down your production branch, require everyone to use pull requests to merge to your master branch, and ensure you never lose critical code.
If you’re ready to get started, sign up for a Bitbucket Cloud account. If you’re already using Bitbucket Cloud, you can add branch permissions from your repository settings menu.
Last year at AtlasCamp we shipped a new integration framework named Bitbucket Connect. Unlike traditional REST APIs, Connect allows you to embed new pages and features directly within the Bitbucket UI via securely signed iframes. It’s kind of like OpenSocial, but with less XML and a far deeper integration with Bitbucket’s feature set. We’ve been using Connect internally to build out new features like Bitbucket Pipelines as independent, full-stack microservices. But even cooler than that: Bitbucket fans have been busy shipping their own user-contributed features to the Bitbucket add-on directory!
Here are six of my favorite Bitbucket features that teams outside of Atlassian shipped this year:
Kanban boards for Bitbucket
Two teams have independently built Kanban-style boards for managing your Bitbucket issues. Kanban boards are great for teams, as you can quickly see which team members are assigned to which issues, and what state the issues are in. Boards also allow users to easily update issues as they progress through your workflow.
Bucket Board provides a simple drag-and-drop board with your issues organized into columns by status:
I typically stick to a simple three column layout, but Bucket Board allows you to configure which status columns are visible based on your workflow needs.
Canvas for Bitbucket is another add-on that provides drag-and-drop boards. It has a few extra features, including BBQL-powered quick filters to restrict which issues are displayed, and the ability to map columns and swimlanes to arbitrary issue attributes:
You can have both add-ons installed at the same time, so try ’em out and see which one suits your team best.
Static site hosting
Bitbucket has a slightly hidden feature that allows you to expose a repository’s contents as a static website. A couple of Seattle-based developers decided they could do better, and built Aerobatic: a GitHub Pages-style static site deployment engine on top of Bitbucket.
Aerobatic supports automatic building of Jekyll sites from any branch in your repository, just like GitHub Pages. Unlike GitHub Pages, they also support Jekyll plugins, Hugo, Wintersmith, and arbitrary npm builds for your site. Aerobatic also have a neat feature where you can serve multiple branches from the same repository on separate subdomains, so you can stage changes to your project’s website before pushing them to production.
Aerobatic do ask a modest fee for their services, but they’ll give you two sites for free (making it a great place to host your personal blog).
As you may have gathered, Bitbucket’s core focus is professional teams. As such, we’ve focused our backlog on features like branch permissions, performance, and perfecting the pull request experience; rather than some of the more fun social features like contributor statistics. Statistics are great for open source projects, and are a handy way to quickly see who has contributed to a particular project. However they’re less useful (or sometimes even dangerous, in the wrong hands) in a professional context: LOC, blame, and commit counts aren’t a great way to measure developer productivity.
But if you dig charts, you’re in luck! A small team of developers from Belarus have shipped some pretty sweet looking charts for Bitbucket. Awesome Graphs (a port of a popular Bitbucket Server add-on) gives you contributor statistics, commit volume over time, and a punch card chart showing what times of day your team is committing code:
Platform.sh is a PHP PaaS that monitors your Bitbucket repositories and deploys the head of each branch to a separate staging environment for testing. This is handy for quickly sharing your work with clients or teammates. It also means pull request reviewers can simply click a link to do some exploration testing of your new feature, rather than having to pull and deploy your code themselves.
For better or worse, I don’t PHP these days, though last I checked ~20% of Bitbucket repositories where the owner had declared a language were PHP.
However if someone was interested in building or integrating a Node.js PaaS with Bitbucket Connect I’d be very interested in chatting 😉 Lucky for me, Platform.sh now supports Node.js, Ruby, and Python as well!
The team behind Awesome Graphs also shipped File Viewer for Bitbucket: an add-on that uses Bitbucket’s File View API to render PDFs, CSVs, GeoJSON, and 3D models. Their latest update includes experimental support for the powerful AutoDesk Forge viewer, which lets you rotate, measure, and explode 3D objects tracked in your Git repositories:
On a slightly more frivolous note, you could also check out this file viewer that renders your source code as a platform game (my high score is 0x0000461c).
Try ’em out!
I’m blown away by the high quality of the features that Atlassian didn’t ship on the Bitbucket Connect platform. If these seem useful for your software projects, check out the Bitbucket add-on directory for a more complete listing of the neat features and integrations available for your Bitbucket account. You’ll need to sign up for a free Bitbucket account (if you haven’t already!)
If you’re working on a Bitbucket feature yourself, or just want to get started with Connect, I’d love to hear about it. Drop me a line on Twitter: I’m @kannonboy.
Following the recent release of U2F support, we’re excited to introduce even more security-related improvements. Over the last few weeks, we rolled out an entirely new SSH stack for Bitbucket Cloud. In addition to our goals of increasing reliability and improving performance, the new infrastructure unlocks some security improvements that many of you been asking for. Today we’re pleased to announce support for the following features:
These improvements are available to all users starting today. The new stack also gives us more visibility into performance of different parts of the SSH process, enabling us to detect performance issues and opportunities for improvement more quickly.
Stay tuned for a follow-up post detailing what we learned from the development and deployment of the new SSH infrastructure. In the meantime, upload your key to get started.
New to Bitbucket Cloud? No problem! Sign up here and enjoy these new features in Bitbucket Cloud.
Several months ago, we released Bitbucket Pipelines Beta to offer a unified and centralized software development workflow for teams looking for continuous delivery solutions within Bitbucket Cloud. Since launch, we’ve gotten a lot of great feedback, and many have benefited from moving faster without losing product quality. In this post, we’ll provide a deeper look at the technical details of Pipelines that makes it such a valuable tool for teams.
Read on to learn more about Pipelines and our latest feature addition, team variables.
Configuration as code for reproducible environments
Getting started with Bitbucket Pipelines is easy. You can enable it in one click and define the build commands your team wants to run in a bitbucket-pipelines.yml configuration file that’s placed at the root of your repository. Bitbucket Pipelines will then start building your commits automatically and publishing the results straight into Bitbucket on every push. Having your team’s pipeline configured as code living in the source code repository not only makes it easy to modify your pipeline but also ensures that the build configuration is aligned and evolves together with the code.
The configuration file will also enable your team to define different build configurations per branch. This way you can seamlessly integrate your build automation with the branching workflow your team is using. Run your unit tests on all of your feature branches and let Bitbucket Pipelines deploy your app when changes are pushed to your production branch.
- echo "This script runs only on commit to the master branch."
- echo "This script runs only on commit to branches with names that match the feature/* pattern."
- npm install
- npm test
- echo "This script runs only on commit to the production branch."
- pip install awscli
- aws --region us-east-1 s3 sync site s3://my-bucket
Save time with fast development feedback
Fast development feedback plays an important role in continuous delivery. It helps by detecting test failures and deployment issues earlier in the process, which leads to shipping products faster. Since Bitbucket Pipelines is built within Bitbucket, it starts building your changes as soon as you’ve pushed them. While your build is being executed, you can track the progress with the logs streaming in real time. In case of a failure, logs will automatically expand the command that failed so you can quickly tell or make a strong guess about the root cause. The build status is also visible at all other places you care about: on commits, branches and pull requests.
When reviewing a pull request you can immediately see your build status in context and click through to find out more about the test failures – all without leaving Bitbucket.
Also, with the latest updates to the Bitbucket dashboard you can now easily filter out pull requests that have failing builds. This way you will avoid wasting time reviewing the code that broke tests. You can instead focus on reviewing the code that actually passed automated quality checks while the broken builds are being fixed.
Use Docker as a build environment
Bitbucket Pipelines uses Docker containers, which makes it possible to create flexible build environments. Docker uses versioned images to define these environments and you can specify the Docker image Bitbucket Pipelines should use when setting up your bitbucket-pipelines.yml file.
As an example, if you have a Node application, select the node:5.10 Docker image as the environment in which Bitbucket Pipelines builds should run:
- npm install
- npm test
You can also create your own Docker image for a fully customized build environment if none of the available Docker Hub images match your build requirements. Bitbucket Pipelines supports both public Docker repositories as well as privately hosted registries.
Apart from the flexibility benefit of running builds in Docker, it is also easy to spin up a Docker container locally. This will allow you to locally reproduce the exact build environment in which your Bitbucket Pipelines builds are executed. Such reproducible build environments can be a huge time saver when debugging failed builds. All you need to do is to spin up the Bitbucket Pipelines build container locally and study the result.
Newly added team variables to Bitbucket Pipelines
We’ve recently added team variables to Bitbucket Pipelines. Prior to adding this feature, if one had to block the access of a specific team or individual to a certain repository, they had to go with per repository access level variables which was repetitive and very time consuming, especially for bigger teams. If there were any changes (i.e. AWS keys), every single repository had to be updated one by one. Team variables make it possible to set up credentials once and for all. They make it possible to create environment variables at the team level and share or reference them in individual projects.
Above are only few of the many features of Bitbucket Pipelines (Beta). This is a big step forward towards the future of development tools in the cloud that are ready to use with a simple click and no infrastructure requirement. Sign up for early access to Beta!
Whether you’re burning the midnight oil at a startup or starting a new project within a larger organization, we want to be part of your Git journey. And in order to do that, we need to be there from the start. So Bitbucket Data Center now offers source code collaboration for professional teams, across any distance, whether your team is small or large.
Keep reading to learn more about what Bitbucket Data Center can offer any team, and how you can grow with Atlassian products.
Bitbucket Data Center is a next generation Git solution
When tools are mission critical to your work, you can’t afford any downtime. It doesn’t matter if your team is made up of 25 or 2,500 people; what matters is that your team can do what needs to be done without worrying about outages. This makes a deployment option like Bitbucket Data Center the solution for teams of all sizes and working together across the globe.
Fo example, if your Git solution gets hit with multiple users and clients (think CI/CD) then you need a highly available tool. Bitbucket Data Center is the only Git solution with out-of-the-box active-active clustering, which provides uninterrupted access to your source code even during an unexpected outage with zero downtime.
For distributed and/or large teams, Bitbucket Data Center provides features like smart mirroring and Git LFS (Large File Storage) to help with performance. Let’s look at a team at Atlassian that fits this bill. The JIRA Software team has teams located in Sydney, Australia and Gdansk, Poland. In a typical workday it’s common for a developer in Gdansk to need access to a repository hosted in Sydney. Instead of having to wait hours to clone the repository, the developer in Gdansk can clone and create a branch from the mirror that we have set up in Gdansk within just a few minutes because of our Git mirroring. By speeding up clone times, our teams aren’t worried about lost development time and can work more efficiently across countries and continents.
Git LFS, on the other hand, is meant for teams that work with large media assets like images and videos. At Atlassian Git LFS helps our designers, tech writers, and build engineers to be more productive when working with developers, because assets can be versioned in Bitbucket Data Center. This means that developers don’t need to shoulder tap or leave their code when working with assets like videos or audio files, because they have the information they need to make exceptional UI experiences at scale. As software development moves more and more into the direction of distributed agile development and even into the land of apps that require large files and slick designs, it’s a necessity for tooling to support various ways of working.
Bitbucket Data Center offers the only solution with default reviewers
Reliability is not the only reason why teams can grow with Bitbucket Data Center. It’s a combination of using highly available tools and features that help teams move fast. A small team might be tired of hearing “We need to move faster,” and a mid-size team might feel the pains of “Our team is growing and we need a more sophisticated way to manage our source code.” Wherever you fall on this spectrum of size, everyone should have the same access to features that help them get what needs to be done, done.
Pull requests are a great example of a feature in Bitbucket Data Center that help teams innovate, because they’re set up to yield quick turnaround times for code reviews and help teams ship faster and deliver value quickly to customers. Pull requests are also set up to include default reviewers and commit-level review. The commit-level review, for example, shows comments within a pull request, so reviewers can see what changes are being made through a code review.
But pull requests are not the only feature built around teams and collaboration. At Atlassian, smart commits give developers the ability to transition JIRA Software issues by embedding specific commands into a commit message from the source code. Developers also use code search to search code to find exactly what they’re looking for, right from the search bar. Pull requests, smart commits, and code search are especially important as your instance, project, and teams grow to keep organized and moving quickly.
Bitbucket Data Center integrates and can be built upon
Besides high availability and features that help growing teams collaborate, Bitbucket Data Center can act as a development platform by setting up integrations. If your team uses existing Atlassian tools, like JIRA Software and Bamboo, you can set up Bitbucket Data Center with these tools for full traceability and continuous integration or continuous delivery.
The Atlassian marketplace, offers hundreds of add-ons to meet your team’s needs outside of integrations with Atlassian tools. Integrations are important to any team and a Git solution needs to support end users, Applinks with other Atlassian tools, API calls, and/or WebHooks without slowing down response times. So the sheer number of end users becomes only one part of a larger story of your greater ALM solution (Application Lifecycle Management) no matter how small or large your business is.
By adopting Bitbucket Data Center as a small team, from day one, you are working with a solution designed for professional teams and rooted in team collaboration. This tool is also now meant to grow with your business as your team grows, wherever you are in the world.
Already have Bitbucket Data Center? Update to Bitbucket Data Center 4.8
As excited about the new developments in Bitbucket Data Center as we are? Share this post on your social network of choice so others can learn what’s new, too!