Bitbucket Server Reviews

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

The permission system for Git repositories and viewing all contributions to a Git repo are the most valuable features I could think of. In addition, it is really nice that users can create their personal repositories.

Stash really helped us to introduce a very granular permission system for our software repositories. Furthermore it makes working with Git a lot easier since users can manage most things with a decent Web GUI.

It is a Java application and runs its own SSH server, and that means that there is a certain overhead on your system. Besides that, Stash really does what it should do.

I have been using this solution for about a year.

No issues encountered.

No, although we have a lot of code stored inside our repositories.

Although we have a huge amount of Git repositories inside Stash, we haven't encountered any scalability issues.

We haven't contacted customer service, so I can't really say how good they are.

We haven't contacted technical support either.

We used Crucible and Fisheye from the same vendor and linked it to our existing SVN and Git servers. We switched because a normal Git installation doesn't provide a permission system.

Everything was straightforward. Atlassian ships Stash with a decent installation wizard.

We implemented it ourselves.

To be honest, I didn't find any solution which did exactly what we needed (besides BitBucket Server).