Initially, we were using other SCM tools that do not have stringent rules that your code should be reviewed first and only then can you commit the code. Bitbucket has push and pull features, that process. When someone wants to commit code, they first pull the code and submit a review request. The request goes to the reviewer and he has to review first, then only he can allow it to be merged.
This process has improved the code quality because every time we commit code it is reviewed by peers, and only then can you commit the code.
It has a distinct tree type of structure that any branch that you need to create can only be a replication of, more or less, of the changes. You can not have a branch that is totally different from the root. This is an advantage but also a drawback. Being a developer, I would prefer to have these kinds of rules. But again, that does not allow me to use the same repository for a different kind of structure so I would need to create a new repository if I am changing the whole structure of the application. You can say both, it is a drawback or it is plus of the application.
Another thing, the time it takes for the repository to get downloaded and be available increases if you are using the cloud version. The only thing we can improve is the bandwidth. If you have low bandwidth and you have a relatively large repository, say more than one GB, it will take a lot of time.
Six to eight months now.
Until now, we haven't found any issues with stability. Once only, there was an issue, we were not able to connect to the application server. That was resolved within some 15 minutes, as soon as we filed a ticket and reported it, it was resolved in 15 minutes. I don't think that there is any issue with stability.
Right now, we are at around 200 developers using it and we haven't found any issue with the scalability.
I haven't called them, but we use their technical support system by submitting a ticket. I would rate it as eight out of 10, their support by email, etc.
We were using something else initially. We switched to Bitbucket as it is a cloud version and we need to support multiple locations; people from multiple locations are accessing the code. Until now, it has been quite helpful.
Because it's a cloud version, we did not need to do any kind of setup with it. We initially started using the trial version of it for 30 days. We created some repositories and started accessing it. Later on, we bought the Enterprise version of it. There were no issues, as such, in setting it up.
We had a few options: Installing it on-prem, and we were also using the previous solution. We found that we prefer Bitbucket as we were going to get good support from a known company. The other thing was that it is on the cloud so we wouldn't have to maintain the server and deal with other maintenance issues. That's why we prefer Bitbucket.
If someone is going to migrate their own code from an SCM to Bitbucket, it could take a lot of time if your code is a bit older. That means that you have larger number of divisions, so it could really take much more time for transferring that to Bitbucket. Otherwise, there's no issue migrating. If it's something that will go directly into Bitbucket, it's just a one-step process.
When it comes to the migration process, because most developers are used to working on other tools, migrating them to Bitbucket takes some time. If Bitbucket had its own migration tool or utility that could be used directly to transfer your SCMs from the older system to Bitbucket, it would have been better. We had to figure out some way or other to do that. If they would have provided something like that, that would have been a plus point.
Overall, it's quite good. It gives you lots of flexibility to use it. It follows all of the site framework. The best practice is that you are required to have your code reviewed before it's committed. Also, there are many layers of permissions that you can apply to a repository.
