It seems like Bitbucket has always been the afterthought in Atlassian's stack. Are Bitbucket Cloud and Bitbucket Data Center still two separate code bases with different APIs?
I'm obviously biased, but we're not an afterthought. I think the best way to explain things is that Bitbucket was a startup that Atlassian acquired; we had to independently solve many cloud-specific problems while the rest of the company was largely still focused on building server products; and as the company started investing in a platform, they prioritized onboarding Jira and Confluence first which are built on a completely different tech stack than Bitbucket Cloud.
The reality is that this migration is one of the clearest signals I can point to that the company is investing in Bitbucket. Our platform teams have been awesome and given us a ton of support, including features that didn't exist before (without going into too much detail... you can probably imagine that Jira and Confluence don't have nearly the same requirements around file system access that we do).
Yes, Bitbucket Cloud and Bitbucket DC are two different teams and code bases; but we work closely together and are talking a lot about both products' roadmaps and future vision. And we even have engineering teams working together on a shared project and may do more of that in the future.
Thanks for the reply. As unsolicited feedback, Atlassian should rip off the bandaid and pick one of the code bases and have that be the go-forward platform for both cloud and on-prem. Bitbucket's two biggest competitors have largely the same code base for cloud and on-prem. The market expects feature parity between cloud and on-prem products and to not have to re-write to a different API when moving from on-prem to cloud or vice versa.
Bitbucket is an acquisition, and I’ve never been especially impressed by Atlassian’s abilities with systems integration. You can always spot the seams.
Atlassian makes me long for Trac, which at first was an epithet, but I’ve come to see it more recently as a distilled product that doesn’t distract from the job at hand. There are a lot of things that get done in the tools because the tools have features, not because the tools are good at it, or because it’s a good way to accomplish a goal.
Mostly what I use are histories, and linking between docs, commits, and builds. If confluence had a way to start a task list in the docs and move it to Jira, that would be one thing, but it can’t even do that. It’s all feature factory work instead of workflow-centric, which is what most of the users actually need.
Yes. And data center is a huge pain to work with in a clustered environment, it almost feels like they want you to not use it and use their cloud offering instead.
Comments
It seems like Bitbucket has always been the afterthought in Atlassian's stack. Are Bitbucket Cloud and Bitbucket Data Center still two separate code bases with different APIs?
I'm obviously biased, but we're not an afterthought. I think the best way to explain things is that Bitbucket was a startup that Atlassian acquired; we had to independently solve many cloud-specific problems while the rest of the company was largely still focused on building server products; and as the company started investing in a platform, they prioritized onboarding Jira and Confluence first which are built on a completely different tech stack than Bitbucket Cloud.
The reality is that this migration is one of the clearest signals I can point to that the company is investing in Bitbucket. Our platform teams have been awesome and given us a ton of support, including features that didn't exist before (without going into too much detail... you can probably imagine that Jira and Confluence don't have nearly the same requirements around file system access that we do).
Yes, Bitbucket Cloud and Bitbucket DC are two different teams and code bases; but we work closely together and are talking a lot about both products' roadmaps and future vision. And we even have engineering teams working together on a shared project and may do more of that in the future.
Thanks for the reply. As unsolicited feedback, Atlassian should rip off the bandaid and pick one of the code bases and have that be the go-forward platform for both cloud and on-prem. Bitbucket's two biggest competitors have largely the same code base for cloud and on-prem. The market expects feature parity between cloud and on-prem products and to not have to re-write to a different API when moving from on-prem to cloud or vice versa.
Bitbucket is an acquisition, and I’ve never been especially impressed by Atlassian’s abilities with systems integration. You can always spot the seams.
https://web.archive.org/web/20160303204710/http://www.itwire...
Atlassian makes me long for Trac, which at first was an epithet, but I’ve come to see it more recently as a distilled product that doesn’t distract from the job at hand. There are a lot of things that get done in the tools because the tools have features, not because the tools are good at it, or because it’s a good way to accomplish a goal.
Mostly what I use are histories, and linking between docs, commits, and builds. If confluence had a way to start a task list in the docs and move it to Jira, that would be one thing, but it can’t even do that. It’s all feature factory work instead of workflow-centric, which is what most of the users actually need.
Yes. And data center is a huge pain to work with in a clustered environment, it almost feels like they want you to not use it and use their cloud offering instead.
The same is true for any of their other products. JIRA/Confluence are the ones that I am most familiar with.