Bitbucket Server Reviews

Bitbucket Server I use for a software repository that has code inside.

Bitbucket Server is easy to use. You can use other applications to access it, or you can use it to access the internet. You can use solutions, such as Sourcetree, which is free, and put it on your development system and use it to do the check-in, checkouts, and those type of operations. It is nice, but some other developers may agree.

I have been Bitbucket Server for approximately two and a half years.

Bitbucket Server is stable.

Bitbucket Server is scalable because the developers are putting things in it they're not supposed to, such as binary data, and it's more or less a text code repository.

We have approximately 150 user licenses. Sometimes vendors will have licenses in chunks. For example, from 50 to 150 or 200. There's no in-between, sometimes you have to buy more licenses than you need.

I have not needed to use technical support. I am good with using this solution and can figure out problems myself or I can use the internet and find a solution.

The initial setup is straightforward.

I can do the integration and setup of the solution. There requires one person to do the maintenance of the solution. The solution is low maintenance. If a patch comes out, and it affects you then you need to do something. If it does not, then you do not need to do anything.

There is a cost to use this solution but it is based on how many users are using it. If you have 50 users or 1,000 users the price will be very different.

Bitbucket Server can be expensive and they want you to purchase their cloud solution. They are getting rid of their on-premises solution, however, you can still find them.

Atlassian tools seem to use Log4j quite a bit, and they should get away from it because of the recent security issues that have happened in the last few days.

I rate Bitbucket Server a six out of ten.

I do a lot of data acquisitions. I establish several contacts and get accounts generated on our clusters so that our researchers can process the data.

We use Bitbucket to get flows for our pipeline management. We outline the scripts that we write to keep them in there for version control.

The most valuable feature of this solution is server management. 

There are other solutions that do that, but this is a solution that the global IT department has available for everyone across the organization.

It would be useful if we were able to work and manage other tickets; for example, if I were to use Jira, Confluence, or Bitbucket, all from a command-line standpoint, in addition to the web interface, it would be incredibly helpful.

I know that there are tools, packages, and different plugins that I can use to collaborate from a command-line standpoint, or through other tools, but putting the functionality into a new version would definitely help.

Some of the capabilities that I am looking for from a command line are not really available.

I have been using this solution for three, four, maybe five years.

We use a few different versions, but they are all older.

It's a stable solution, but there are times where it's indexing, and if it happens during the time that I am using it, then it's not very stable. We have been using it for years, so there is a lot of data.

It's scalable. The newer cloud versions of the tools may or may not alleviate the issues with stability, which is a problem with the version that I have.

I have not contacted technical support.

They have a community. If anybody has a question they will be willing to help and blog posts.

Anybody can look at to learn more about their products and how to use the different solutions that they have.

A lot of what they have is for the new versions, which are cloud-based. For example, they are actively working on different plugins.

We use Amazon and Google Cloud storage solutions. Also, AWS buckets, GCP buckets, and Kubernetes, but it depends on what's in the contract and available for the researcher, for both internal and external applications.

I was not a part of the initial setup.

I am not familiar with how it is set up. It was done through our global team and made available for the company.

I am not aware of the pricing.

If anybody was considering this tool, I would be expecting that they would really evaluate it and know what the functionalities are ahead of time.

There are other tools that are similar, so make sure to look at everything available in that space and make sure it fits their needs.

I would rate Bitbuck Server an eight 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.

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.

• 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.