Bitbucket Server Reviews

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.

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. 

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.

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

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.

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.