Bitbucket Server Reviews

The use case for Bitbucket is a good repository manager for the code base. It is one type of version control system on the cloud.

The platform's most beneficial feature is the repository for our code base. It helps with versioning, Git collaboration, merging, and cloning. It can efficiently promote code to different environments, like development to UAT and production.

The platform's integration with other cloud services should be improved.

I have been using Bitbucket Server for four years. 

The product stability is excellent on the cloud. I rate the stability on-premises at about nine out of ten.

The technical support services are good. 

The product doesn't require any setup when deployed on the cloud. Whereas, we have to follow a deployment process for the on-premises version. 

Pull request features are essential for verifying repositories on the cloud and should be pulled to the local workstation. Pull requests (PR) help merge branches and are part of Git collaboration tools like Bitbucket and GitHub.

The current trend in our industry is towards highly integrated systems. Most companies are choosing their software development lifecycle tools based on integration capabilities. So, integration is a key focus right now.

I rate Bitbucket Server nine out of ten. 

The product’s most valuable features are private repositories and the ability to work as a proxy for implementing CI/CD pipelines.

The product interface consists of multiple features that are complicated to navigate for new users. They could make it easier to access and introduce templates with sample code for beginners to understand Kubernetes deployment.

We have been using Bitbucket Server for eight years.

It is a perfectly stable platform.

We have 37,000 Bitbucket Server users in our organization. We plan to increase the usage.

We use Jira and Confluence.

The initial setup is simple for me as I am an experienced developer. For our private cloud setup, the process was streamlined, given the enterprise-level support and production coverage.

Bitbucket significantly improves our code review and collaboration processes by providing private repositories as a default feature. This specific feature was not available in GitHub at the time of our selection. 

We utilize a standard Gitflow with feature branches, including branches like bugfixes, hotfixes, and more. It makes the request mechanism easy to use.

Its integration capabilities with other tools have been useful. However, the integration with Slack needs improvement. It provides satisfactory performance and scalability for our site.

I recommend it to others and rate it a nine out of ten.

I use Bitbucket Server to store code. 

The tool makes pushing codes and setting up CI/CD pipelines easy. 

Bitbucket Server has limited user support for its free version. It is expensive. 

I have been using the product for two years. 

I rate the tool's stability a nine out of ten. 

Bitbucket Server is scalable. 

I have worked with GitHub and GitLab. 

The tool's deployment is straightforward. 

Bitbucket Server's deployment can be done in-house. 

Bitbucket Server saves a lot of money. 

I rate Bitbucket Server a nine out of ten. 

Horizontal scalability & high availability are the most important features that we are looking forward to from the Stash DC. With respect to the premier support, timely response and the fact that we have assigned representatives is great.

The premier support has helped Cisco in mitigating risk and reducing cost.

Will let you know in a couple months. Still in the process of evaluating the product.

We use Stash Data Center and Premier Support. We have been using it since January 12, 2015.

None, so far.

Testing under progress.

In production, we still have the single instance of the product and it has scaled pretty well and no major issues reported thus far.

Very good but I have some feedback with respect to the support.

1) Currently, we have a limitation of 3 resources for interacting with Atlassian support. It would be nice to increase it to 5-10 because we have to internally depend upon identified users to communicate to the Atlassian. Or else, have this support aligned to the Cisco mailer alias so that multiple users within Cisco will be notified and can use the same user name to raise support requests with Atlassian.

Very good but would be good to have a user interface in Atlassian.com to manage the users at our end instead of having to communicate each time to the premier support to manage users.

We are still using SVN but we moving toward git because of the flexibility it provides.

Nope, our engineering wing had done some analysis and they suggested Stash. Hence, we directly jumped in.

If folks out there are looking to move to a more agile approach for development, Agile Jira + Bamboo + Stash DC will definitely be a great way to go since these systems seamlessly integrate with each other. Premier support is definitely recommended.

• We selected Stash primarily because we believe it has the most potential to become the best product available, not because it was the best product available at the time. Since 2013, Stash has been significantly improved in many ways such as the introduction of Pull Requests, demonstrating that this belief in the potential continues to be valid.
• We like that Stash has a full development staff behind it, and that Atlassian is investing in using Stash internally, as this ensures that Atlassian is committed to the development of Stash to become the best solution available.
• We like that Stash uses the Atlassian Plugin Framework. We have had success extending all Atlassian tools using custom plugins both that we have written in-house and as well that we are using from external 3^rd parties. This gives us some flexibility to complete features that are important to us that are either not shared by other Atlassian customers, or where the feature has not yet been prioritized by Atlassian.
• We like the simple per- 1000 user pricing. Although, per-user pricing might be preferred, the per- 1000 user pricing is still competitive with other commercial source management solutions. And, the pricing based upon # of users instead of amount of server hardware allows us to the flexibility to invest as much as we want into infrastructure without being penalized for having a faster system by being forced to pay more for a higher level of service.
• We like that Stash is supported under Linux. Linux is our preferred server platform.
• We like the LDAP authentication and directory integration. This allows us to integrate with the corporate directory and define access using the corporate directory accounts.
• We like that Stash supports both SSH AND HTTPS. There are use cases that are best fulfilled by either mode. SSH is a best choice for automation and access for a single user. HTTPS is best for more ad-hoc clones, including to work with shared clones owned by a shared or service account where multiple users may be authorizating operations done against the same clone.
• We like both the Fork model (most users work in private forks) and the project branches model (everybody works in the main repository). Different teams have different requirements and expectations around how a source management system should ideally work. One model doesn’t fit all product teams.

Our use of Stash is still limited (500 users or less). There are certain functions still missing that are needed to scale it out to a wider set of users and product lines. The primary benefit being realized today, is that Stash provides us a simple and good management interface to allow us to give product teams a self-service, corporately supported, horizontally scalable, Git hosting solution that integrates with other important tools for our company such as JIRA.

Key areas of improvement that I would like to see are:

1) Stash Data Center provides horizontal scaling within a single data center (i.e. low latency between components, components share a database and backend storage). Stash Data Center is missing “remote site” capabilities – whether more like a Git CDN where it can cache content at the remote sites, authorize the fetches from the central site, and then serve locally at LAN speed, rather than WAN speed, or whether like Stash Data Center horizontal scalability, but allowing long-distant (higher latency) links, and separate database and backend storage that is local to the site that it is hosted at.

2) More access control capabilities including granular access, and ability to do such things as enforce the use of Pull Requests for all merges.

3) More process enforcement capabilities, such as ensuring that particular people Approve a Pull Request before it can be Merged, or that a JIRA is associated with the Pull Request before it is allowed to be merged. In the mean-time, it looks like we will need to implement this for ourselves.

4) Missing commit graph feature should be integrated into main product.

5) Missing statistics and graphs similar to what Crucible provides.

6) Large file support. I know this is a Git architecture problem. However, I think the community needs to solve this problem, and having a hosting solution like Stash may offer options if the community could agree on what the solution should be. For example, I believe Mercurial support for big files is often done by treating large files as links to a central resources for the file content, and then the file content is downloaded on demand. Perhaps a type of light-weight clone where large file versions can be downloaded on demand only.

Stash since June, 2013. Stash Data Center since December 13, 2014.

I have not yet deployed Stash Data Center. We are still using a one-instance Stash. But we plan to use Stash Data Center soon.

Mixed. We’ve experienced really great Atlassian support from several years ago. As Atlassian grew, we have noticed a reduction in consistency of how issues are resolved between products (i.e. JIRA vs JIRA Agile vs Confluence vs Crucible vs Stash), as well as in terms of how they get handled for the same product. For example, sometimes when we open support.atlassian.com they will tell us that bugs should be reported on jira.atlassian.com. Other times, we’ll open a bug on jira.atlassian.com and the issue will be prematurely closed with a support request opened. It can be intimidating for some of our staff who are just trying to figure out what the right thing to do is. For myself, I’m very comfortable wording the requests appropriate for support.atlassian.com or jira.atlassian.com and making the right call, and I only rarely need to escalate in some way in the form of a complaint. Other examples have to do with the resolution of issues, whether sometimes a user will provide a work-around or even a solution, such as a few times I received Crucible patches to fix my problems, whereas other times very simple issues would sit on jira.atlassian.com for months or years before getting attention. I realize it is difficult to run a larger company consistently, but unless you know what the problems are, you can’t work on improving the situation.

Mixed. We’ve experienced really great Atlassian support from several years ago. As Atlassian grew, we have noticed a reduction in consistency of how issues are resolved between products (i.e. JIRA vs JIRA Agile vs Confluence vs Crucible vs Stash), as well as in terms of how they get handled for the same product. For example, sometimes when we open support.atlassian.com they will tell us that bugs should be reported on jira.atlassian.com. Other times, we’ll open a bug on jira.atlassian.com and the issue will be prematurely closed with a support request opened. It can be intimidating for some of our staff who are just trying to figure out what the right thing to do is. For myself, I’m very comfortable wording the requests appropriate for support.atlassian.com or jira.atlassian.com and making the right call, and I only rarely need to escalate in some way in the form of a complaint. Other examples have to do with the resolution of issues, whether sometimes a user will provide a work-around or even a solution, such as a few times I received Crucible patches to fix my problems, whereas other times very simple issues would sit on jira.atlassian.comfor months or years before getting attention. I realize it is difficult to run a larger company consistently, but unless you know what the problems are, you can’t work on improving the situation.

Some of the product teams ran their own Git servers… either an anonymous “git” daemon, or one of them may have set up something like Gitorious. We didn’t have an official instance running anything until Stash.

Stash was easy to set up. Stash Data Center still TBD.

This has not been calculated yet. To some significant degree, we are looking for improvement in designer productivity and capabilities, particularly when it comes to our use of free / open source software that is published using Git such as Linux, and a reduction in cost compared to solutions such as Perforce and ClearCase that we also heavily rely on. Stash is still a bit of an experiment to us, although it is a successfully running experiment, and more teams are looking to switch and migrate from either Perforce or ClearCase.

I considered using Gitorious and a few other options. However, they were clumsy to set up and I didn’t feel they would give us what we need in the long term, so I quickly aborted once I discovered that Atlassian Stash was available in 2013.

Learn Git, and learn how the Stash developers intend for you to work with Git. It is a lot easier working with the system as it is intended to be used, then trying to use Git just like you would use another system such as Subversion, Perforce, or ClearCase today.

We have this solution integrated into our CI/CD ecosystem along with Jenkins, Bamboo, and JIRA.

Bitbucket is just a tool. The important part is knowing how to evolve towards a "trunk-based" development model, which implies all SW development must always be "testable/ready for PROD deployment". This implies integrating/automating using many tools.

The Pull Request GUI is good. Integration of Bitbucket with JIRA & Bamboo is well done by Atlassian.

Implementing DevOps CI/CD is easy to implement after a "trunk-based" development model is adopted.

Instead of providing only raw features and plugins, Atlassian should provide a ready-to-use integration of both choices to incorporate "trunk-based" development. For example:

• JIRA / Bitbucket / Bamboo 

or

• JIRA / Bitbucket / CloudBees-Jenkins

Four years.

Atlassian support is very good.

It shows any contact records at the backend. But, if we face any config guard, any filing data, or any formatting error, then we can easily monitor in the Bitbucket pipeline itself. If a specific branch of code has an error, we have to look into that particular branch instead of looking into the overall code, and overall backup.

If I want to mail someone a master branch, then sometimes it shows some conflict with other codes in the master branch.

When we clear that master branch, clear those lines, resolve them, and try to push again, it shows the conflict error. It's some kind of server issue or it's some kind of different particular brand issue. When we try to push the specified code, instead of that, sometimes it automatically saves all local files, which are available in the particular branch. 

Then we get a server issue. When we are faced with this problem, we need to remove that particular branch, and we once again, create the new branch, and once again, pull the changes around.

I have been using Bitbucket Server for two years. 

The solution is easily scalable.

The initial setup is straightforward. It takes half an hour to deploy. 

Overall, I rate the solution a seven out of ten. 

A direct single contact to Atlassian for needed functionality who can provide Roadmap information and be a voice for our company at Atlassian.

He helped gather information about how Stash works so that we could make an educated decision on how to handle system administration support – including items like backups, how easiest to grow adoption with limited support staff, and how to consider future integrations between Atlassian tools and our internal tools.

More input/visibility to what features are important to other Enterprise customers (without providing enough details to determine who the enterprise customer is). Being able to react if a certain feature is of extreme importance and work to bring more light to that request at Atlassian. i.e. we saw a feature that had been heavily requested by customers that was very important to us and having a TAM didn’t get us much traction on getting this feature.

We purchased a Technical Account Management (TAM) in July 2014. 

Our TAM was able to help us when we had issues with deployment. 

Our TAM was able to help us with stability issues. 

No issues with scalability that our TAM was able to solve. 

Yes – We haven’t switched completely but it is starting to gain more traction than other solutions like Gerrit. We have also been using and will continue to use Rally with our JIRA instances.

Straightforward in most ways – install, configuration. Some parts were more complex – SSL, LDAP groups pulled in to manage security in a low maintenance way.

Yes many – GitLab, Gitolite, GitHub, git. Gerrit. We have also been using Clarity, Rally on the ALM side.

Are you looking for someone who can help your strategy for deploying one or more Atlassian products, then I would go with TAM. If you need more support for running the Atlassian products (issues, outages, performance), then Premier Support is the route to go.