Scaling in Bitbucket Cloud: new features and reliability numbers | Hacker News Reader

Scaling in Bitbucket Cloud: new features and reliability numbers

blog.bitbucket.org

91 pointskannonboy41 comments

The Bitbucket UI is a mess.

* It takes over your native browsers find feature.

* It's javascript heavy and has multiple panes that scroll, collapse, and expand.

* Viewing diffs requires you to click each file that changed (unlike every other diff/code browser I've used where it has one long page with all the changes)

> * Viewing diffs requires you to click each file that changed (unlike every other diff/code browser I've used where it has one long page with all the changes)

This is not my experience. Picking a random project I see a listing of all changes in all files: https://bitbucket.org/atlassianlabs/asap-cli/pull-requests/3...

That's for a pull request, this is for a branch: https://bitbucket.org/atlassianlabs/asap-cli/branch/bump_dev...

I'm using the "enterprise" version, not the public version. Maybe there's a difference. And yeah, that view you posted is a lot easier to read.

Can confirm. The enterprise (aka Bitbucket Server) version gives you a two pane layout, with files on the left and changes to those files on the right.

Bitbucket Server (formerly Stash) is a completely different codebase from Bitbucket Cloud. They share zero code. One is written in Java, the other in Python. It's a constant source of confusion. The naming is because of a terrible marketing decision. Atlassian marketing does all kinds of weird things, like advertising Bitbucket as only supporting git despite also supporting mercurial.

Almost as bad as Skype vs Skype for Business

Might want to check and see how far behind you are in upgrades. Even though the on-prem version will never have feature parity (new features hit cloud first) it could be that whoever runs your instance hasn't upgraded in a little while.

Feature parity is not really a goal of these products - they are totally separate teams, technologies and languages. If one team develops something awesome then of course the other will try to reimplement, but it's not really the case that features "hit cloud first".

You're saying the BitBucket cloud and server teams are using totally separate technologies and languages? That's not the impression I've gotten at all at every atlassian conference I've been to. Seems wasteful but nothing surprises me anymore.

I actually prefer bitbucket cloud to github. The pull request workflow in particular is a lot cleaner. Currently ditching both for gitlab tho.

Glad to hear you're switching to GitLab. What made you switch? And how can we maybe improve our pull/merge request workflow?

And this is why github won...

I'm a Bitbucket Product Manager. Thanks for the feedback! This is an area we plan to improve in the Server offering. In particular we're actively looking at ways to make diff nav and find much better.

Are you planning on adding code search feature any time soon (in the cloud, that is)?

Bitbucket PM here, We are currently working on code search for Bitbucket cloud, you can follow our progress here: https://bitbucket.org/site/master/issues/2874/ability-to-sea...

It sounds like you're talking about Bitbucket Server. This article is about Bitbucket Cloud. Some people (myself included) much prefer the Cloud product, some people love the server product - and often they have these opinions for the same reason. File-by-file diff is a good example of this :)

Disclosure, I work for Atlassian, but not on either of these products.

We use Bitbucket (for over 4 years now) and in general like it mainly for its pricing model. However I have the (generally unfounded) fear that it will become bloated and slow like several other Atlassian products. I have really grown to dislike Jira but I will save that complaint for some other time.

The Bitbucket UI has improved over time but my real annoyance is the "Recent Activity" list is not wide enough and is not very configurable (ie filtering).

Also Bitbucket has sort of forgotten its Mercurial roots. Many Mercurial features have been added but it appears the Bitbucket UI does not show these features (for example Mercurial tracks moved files but Bitbucket does not show this).

The pipeline looks interesting but it is just a little too late for us since we are so heavily invested in Jenkins + Bash and will probably use Jenkins pipeline (Groovy) in the future. And if we do more opensource stuff it will probably be on Github so we will continue to use Travis. Also in all honesty I'm fairly sick of the whole YAML configure the world explosion... I actually miss XML but would prefer a scripting language over YAML (then again maybe I'm the only one who hates YAML).

Finally why is the Bitbucket blog so darn slow?

(I added this critique because I saw a Bitbucket PM floating around here).

I can't answer the PM questions, but the Bitbucket blog is hosted externally, not on Bitbucket itself.

> heavily invested in Jenkins + Bash and will probably use Jenkins pipeline (Groovy) in the future ... would prefer a scripting language over YAML

Do you really want to switch to Apache Groovy? Bash is pretty standard for scripting *nix whereas noone knows what the standard is for scripting the JVM?

I've used and loved bitbucket for years for private project hosting, but for the occasion where I need to put more devs on a particular project I'm not sure why I would pay for it now over using gitlab for free. It might be different if it was 5 users per project for free, but 5 collaborators across all of my projects is just too limiting - especially when I can get everything bb has and more from gitlab.

At the same time I understand bb needs to make money - hopefully they'll make enough to keep up the competition.

  > I understand bb needs to make money

They're an Atlassian product, they're pretty ok on the cash-money front.

Have you noticed any drawbacks to using Gitlab over Bitbucket/Github?

admittedly I haven't used gitlab to the extent I have with bitbucket/gitlab - but so far I haven't found anything missing personally - in fact there a lot of things in gitlab that I wish were in the others. A lot of the github enhancements lately have been things that gitlab had first.

The only real downside at the moment is for public open source github is still the place everyone is expecting you to be. Its hard enough for small projects to be noticed on github, putting them somewhere else means nobody will ever see them just browsing. But for private or private-for-now projects gitlab seems to be the best fit for me currently.

Not OP, but as a majority user of Gitlab the only downside is integrations. By that I specifically mean Codeship. It's just not considered a first class citizen to some yet, which is unfortunate.

For us at Codeship, it has nothing to do with not taking GitLab seriously, not treating them as first-class citizen, etc. We'll add GitLab support, hopefully, sooner than later. There are simply other feature requests that are more important for existing customers that are already using Codeship.

Sure, and just to be clear that wasn't me straight griping. Completely understand you guys have priorities. Just doesnt change the fact that it's an existing pain point for heavy Gitlab users.

Codeship support might happen, see https://news.ycombinator.com/item?id=12697135

In the meantime, is there anything that we can improve in GitLab CI to make your switch possible?

To be completely honest - probably nothing. This is a legacy issue on our end, not yours. I haven't even taken the time to explore migrating our GH/Codeship builds to GL CI. We essentially mirror our repos amongst both offerings at the moment, running builds via Codeship until either they support GL and we can drop GH, or we get the time to spend on a proper Codeship => GH CI migration and we can drop Codeship. Anyone's guess what will win out at this point :)

Appreciate the response either way.

Thanks for the reply!

I was recently looking at BitBucket Data Centre, to move our in-house git server to something with better clustering & high-availablilty & failover (rather than doing it ourselves). I was a little disappointed to find out the HA features are provided by storing your repos on an NFS server, and detaching/attaching it to the primary node.

Bitbucket PM here, sorry to hear this doesn't suit you. Could you tell me more? If like to better understand your concern.

Sure! We don't have any NFS infrastructure, so migrating to BitBucket means paying for the license + some kind of SAN + engineers to look after it.

We'd much prefer to use EFS but I understand that it's not supported, since there's no way to set `lookupcache=positive` (git push might update the ref to an object which may not be immediately available across all NFS clients & they would cache that the object doesn't exist unless this is set)[0]

[0]: https://docs.gitlab.com/ee/administration/high_availability/...

The real clincher is that if we can set up HA NFS, then we might as well migrate our existing git solution to it and save ourselves the license cost…

I think they just announced that AWS is a first class supported platform (I'm here at their conference) so it might be worth looking again. Of course that might be Data Center products only so don't quote me on it. I'm sure someone from Atlassian is around here and can confirm.

Bitbucket user for many years now, and I was on the Pipelines Beta. Pipelines is pretty cool IMO - we set it up to automatically upload websites to S3 and invalidate CloudFront caches as soon as code is git pushed to BB.

Bitbucket is Nice, but why the 1GB/2GB repository limit, especially for paid users (entreprise version) ? Never understood this limit...

Doesn't really matter that they've made Pipelines available for all users when it's lacking some pretty basic functionality. Like the ability to do something on failed builds.

But other than that it looks really good and responsive. Going to be interesting to see how the influx of new users will impact the average build time.

Hi vegardx, I'm the lead Product Manager on Pipelines. First of all, thanks for your comment. It's still early days for us but we've had some great feedback from beta customers and making it available to all customers allows us to help a lot more teams on Bitbucket. Regarding the failed builds you can use webhooks [1] today to trigger actions after the pipeline completes and we'll work on extending this capability in the future.

Our first focus was to make a platform that can scale on demand without hard constraints on the number of containers running. We know that we have some gaps to fill but we're now moving fast and we've added several features in the past weeks (repo status, notifications, pipelines statuses everywhere).

Thanks again for your feedback. Let me know if you have any questions.

Sten

[1] https://confluence.atlassian.com/display/BITBUCKET/Notificat...

If I pay $10 for 1000 additional build minutes will those additional minutes roll over month to month, until they have been used?

Pipelines PM here. The model is a bit different, it's a pay as you go per blocks of 1,000 minutes. So if you normally use an extra 2,800 minutes per month you'll pay $30/month usually, but if for some reasons youd don't use it as much and drop to 1,500 extra minutes the next month you'll pay $20 for that month instead of $30/month every month of the year. For this reason we don't carry over minutes month to month.

Sten

I would like to carry minutes over. That would be far better for a solo developer like me, as I may need only 200 minutes a month, but I am stuck paying $120 a year in your model.

Much as I like Bitbucket I think either hosting my own CI and CD infrastructure on a cheap VPS or using gitlab is the way to go.

Reply on news.ycombinator.com