Bitbucket Server Review
Stash provides us a simple and good management interface to give product teams a self-service, scalable solution.


Valuable Features

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

Improvements to My Organization

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.

Room for Improvement

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.

Use of Solution

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

Deployment Issues

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.

Customer Service and Technical Support

Customer Service:

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.

Technical Support:

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.

Previous Solutions

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.

Initial Setup

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

ROI

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.

Other Solutions Considered

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.

Other Advice

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.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
4 visitors found this review helpful

1 Comment

it_user205335Real User

I concur Mark. I really like that we can open branches from JIRA issues directly into Stash. That integration makes it easy to work with.

09 March 15
Guest
Why do you like it?

Sign Up with Email