Bitbucket Server Reviews

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. 

I use the solution in my company for traditional projects. Now, my company plans to move our projects to GitLab since it provides a single UI for everything.

Bitbucket Server creates a branch and is useful for authentication, commits, and pushing changes.

Bitbucket Server is a standalone tool or server. My company also uses Jira. In our company, there are different kinds of tools linked together by webhooks, and we use Jenkins to run Bitbucket Server. GitLab provides an integrated solution, so everything is available in a single product. With Bitbucket Server, you can see the codes, configure the pipelines, and you can merge a pull request. Bitbucket Server may be even better than GitHub. With GitLab, you have a single solution in one place, so it is not scattered in many places, like in the case of Jira, Jenkins, or Bitbucket Server, making it a better option for our company. From an improvement perspective, Bitbucket Server should make everything available as a single solution.

I have experience with Bitbucket Server.

In our company, Bitbucket Server has a backend link to Jira. When Jira is down, Bitbucket Server is also down.

It is an okay tool in terms of scalability. Though I am unsure, I feel that Oracle DB is used in the backend. In our company, when we have to create new reports in the backend database, you just increase the hard disk. Another team in my company controls the aforementioned area associated with the product, so I don't know it in detail.

Considering that all the developers in my company use the product, I would say that around 30 percent of the people in my company use the solution.

My company decided that since Zscaler is on the cloud, we need a local on-premises server.

The product's initial setup phase is complex. GitLab is better to deal with when it comes to the setup phase since it uses the YAML script. With GitLab, one can use templates for almost all projects, so a given project can be dealt with based on the templates, and sometimes the templates might have to be updated a little bit. In Jenkins, every project is treated separately, so you have to create every project on Jenkinsfile. It cannot be based on some templates, and I feel it may be a little bit complex and not as easy as GitLab.

One needs to pay towards the licensing charges associated with the product.

I am planning to move to GitLab.

In terms of the most valuable feature of the tool for our company's current collaboration, I would say that since the product is deployed on an on-premises model, you can easily control the branching strategy, merge strategies, and code review.

The pull request feature of the tool streamlines the code review process in our company, after which we invite some people to review it and then change the policies if needed. All people involved in the process of reviewing should provide approval based on which the company can delete or merge branches.

For the improvement of CI/CD pipelines, my company uses Jenkins to check the pipelines from the Bitbucket Server. In the pipeline, our company can link to Jira or Confluence and deal with checkout, clone, compile, and then do the test and generate reports.

I recommend the product to others, especially small companies because you can get a cloud solution for your organization, and also, it is similar to GitLab and GitHub. One can work with Bitbucket Server, Jira, and GitLab, along with CI/CD pipelines. Small companies also need not set up on-premises servers and should prefer cloud services.

In terms of benefits, I feel that many companies are moving to Bitbucket Server since it can be deployed on an on-premises model at a time when everything is being moved to the cloud. GitLab can be used by those who want to move to the cloud.

I rate the tool 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.

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.