Bitbucket Server Reviews

It would have been better to use Bitbucket Server if it had something similar to the concept called GitHub Actions since it allows GitHub to provide seamless integration of CI/CD pipelines.

I have experience with Bitbucket Server. I am a customer of the product.

It is a stable solution

It is an easily scalable solution.

I don't have experience with the solution's technical support. I rate the technical support a seven to eight out of ten.

Neutral

I have experience with GitHub and GitLab. Compared to GitHub and GitLab, Bitbucket Server provides better security levels of verification. Bitbucket Server's pricing options are cheaper than GitHub and GitLab. In general, GitHub is much better than Bitbucket Server. Bitbucket Server's prices are cheaper than GitHub.

The product's initial setup phase was neither a difficult nor easy process, making it a moderate process. GitHub is much easier from a deployment perspective, especially from the CI/CD angle for continuous integrations and deployments. Security-wise, Bitbucket Server offers some additional steps allowing you to use a secured authentication process, like single sign-on, authenticated sign-on, or additional two-factor verification, which is better in Bitbucket Server compared to GitHub.

Bitbucket Server enhances collaboration in our company's development workflow since its users are developers who use CodeCommit. Areas like release planning and code movement from development to integration to testing and from production to deployment are managed with Bitbucket Server. Most of the code repositories are also on Bitbucket Server.

The features of Bitbucket Server that I found most beneficial for source code management stem from its integration capabilities with code repositories that are supposed to be from different branches. Basically, integration is easier in Bitbucket Server. Deployment is also pretty seamless across from Bitbucket Server's side. Fetching the code from the repo branch and deploying it is easy.

Bitbucket Server's pull request feature impacted our company's code review process since any kind of difference in the code could be analyzed more easily. The branches could be analyzed better, while the CI/CD integration is also pretty easy with Bitbucket Server. The tool shows you the whole branch of how the code is being used. The data lineage is pretty seamless.

There is a separate team in my company that takes care of the maintenance part of the product.

The integration of Bitbucket Server with other Atlassian products improves our company's project management since we get to know the status once we commit the code as the CodeCommit status is usually reflected in Jira, and it is easily observable allowing users to see what changes have happened. Users can get a unified view of each task or each project, along with details on what code is associated with which step and how Jira commits across. The tool provides a single unified view for code management and project planning.

Bitbucket Server's permission management helped maintain the security of our company's code base, as it is an area that has to do more with the authentication and authorization levels.

I rate the tool a seven out of ten.

Bitbucket Server serves as our source code management and version control platform. Like Azure Repository, we utilize it to store and manage our source code. The integration of Bitbucket into our Software Development Life Cycle process is crucial. However, it's important to note that the product does not provide code approval functionalities. We may need to employ additional tools, such as Jenkins, for code approvals. Additional tools from Jira and Jenkins help in the CI/CD process. 

Bitbucket Server supports code collaboration by providing commands developers can use to check in code. Through comments, developers can specify the purpose of the code check-in. Additionally, Bitbucket allows tagging of code for releases.

Bitbucket Server can experience performance issues when pushing a large amount of code. This process may take a considerable amount of time.

I have been using the product for three to four years. 

The product is generally stable, with occasional hiccups or errors that might occur.

The solution can be scaled vertically or horizontally as per the requirement. My company has eight to ten users. 

The tool's support is standard. They respond as soon as possible. 

The tool's deployment requires expertise since its environment is on-premise. To deploy Bitbucket Server, you must run the standalone executable file and set up the database server since it stores metadata in the database. Additionally, you'll require a shared folder to keep the actual code. Configuration of URLs and a server proxy are necessary for the deployment process. There are one to two engineers who manage the tool. 

The solution's deployment requires a consultant. 

The tool's licensing costs are yearly. Prices can become expensive if you have a lot of users. 

The product is good, but its features are limited. It is a good choice if the requirement is solely to manage source code. It handles source code management, providing stable check-in and check-out functionality and features like comments and tagging. You can set permissions at the project level, repository level, or branch level. Project-level permissions apply to all branches and repositories within the project. Repository-level permissions are specific to the branches within that repository. I rate it a seven out of ten. 

The solution can easily integrate with Jira and other Atlassian products. 

We use the tool as a code repository. It is also used for tracking tasks, logging issues, solving issues, and CI/CD deployment.

We don't have any issues in terms of performance and stability. The product has its own tracking facility or features, although it is limited. We use Jira to work around the limitation.

There’s no integration of the tasks defined in Bitbucket that go to Jira. We define the task on Jira and then connect it to Bitbucket. The task or the issues defined on Bitbucket must be transported to Jira. The tasks on Bitbucket must be automatically integrated into Jira.

I have been using the solution since 2016.

The tool is stable. I rate the stability a ten out of ten. We don’t have any problems with stability.

We don't have any problem with scalability. We're able to create many projects and repositories. We don’t have many developers. We only have around 20 people working on a particular repository in Bitbucket. It's easy to manage.

We have had no problems with support. Most of the technical issues we query are about the Bitbucket pipeline and integrating or deploying the application to different platforms like AWS or Azure.

The setup is straightforward. It takes less than an hour to set up a repository. We’re using Bitbucket Cloud for the developers to use the repository. Some developers would use the traditional Git client on their workstations, and some would use the GUI-based Git interface to communicate with Bitbucket.

Our code is secure. It is easy to collaborate with our developers. It is easy to monitor their tasks. It's easy to deploy the application because everything is automated. It's cheaper to use the cloud.

Before, we acquired GitLab licenses, which we implemented on-premise. It required a lot of maintenance. We had to regularly ensure that the GitLab deployment was always updated and secured. It needed a lot of monitoring and maintenance.

It is better to use Bitbucket. We do not have to maintain and monitor the server regularly. We can focus on using the product and storing our code.

We're paying a monthly subscription per user. We pay around $6 per user. We also pay for Jira for task monitoring and management.

We have moved the task management to Jira. We use Jira to define all the necessary tasks properly and do the necessary monitoring. We allow access to our customers only to review issues. Teams that need to perform DevOps tasks using Bitbucket must buy the premium subscription. The free edition has a limited number of users and features. We will not be able to utilize its capabilities fully. Overall, I rate the tool a ten out of ten.

We mainly use Bitbucket Server for CI/CD. We had around two to three members working on the same project for automation. To manage version control, we used Bitbucket to collaborate and integrate with other resources. 

We created separate repositories for each endpoint, including API endpoints and different applications. We also set up separate pipelines for each of them. The customer had a specific requirement, so we created the necessary repositories and hosted the configuration server.

Earlier, we configured triggers and hooks on the Bitbucket Server. This setup allowed automated triggering whenever someone pushed code to a branch. Depending on the trigger, the pipeline would run on BuildKite or another CI/CD tool.

The most valuable feature is that it has its own pipelines.

The UI could be enhanced.

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

We never had any downtime, performance issues with the Bitbucket Server.

10-12 members are using the Bitbucket Server.

Initially, we started using Bitbucket Server about a year ago, primarily for managing our build processes with the build guide. Since then, we have increasingly adopted Python. Initially, we had only two repositories, but now we have expanded to twelve to thirteen repositories.

Bitbucket has a lot of features compared to GitHub.

The initial setup is straightforward.

If you're going to use a version control system, Bitbucket Server is a good choice.

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

When working on code development or maintenance, the initial step involves pushing the code to a central server, to manage code changes and additions. Bitbucket Server is commonly used for pushing and pulling code and plays a pivotal role in this process.

Its standout features are the seamless integration with various intelligent tools and its user-friendly nature.

There are instances when I interact with Bitbucket and encounter a situation where I've pushed changes to the website server. However, when I access my branch on the website server, I notice that the changes are not immediately reflected. Enhancing the real-time reflection of changes online is an area that could benefit from improvement.

I have been working with it for one year.

It offers good stability capabilities.

It demonstrates high scalability, which is essential for my company's substantial workforce, consisting of approximately eight to nine thousand employees. Within my team, we rely on it as our version control system, and nearly two hundred team members actively use it.

In the rare event that we faced downtime, the admin and other teams promptly addressed and resolved the issue.

Neutral

Before we switched to Bitbucket, the company was working with GitHub on the server. Bitbucket is known for its user-friendliness, and personally, I find it very easy to work with.

The initial setup is quite easy.

I would recommend it as it serves as an excellent platform for code maintenance. I would rate it eight out of ten.

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

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.