3 ms·

We moved from BitBucket on premise to GitLab CE on premise. Actually most things now just works. Updating is a breeze. Instead of downloading a installer and co

by merb 10y ago

We moved from BitBucket on premise to GitLab CE on premise. Actually most things now just works. Updating is a breeze. Instead of downloading a installer and copying / fixing server.xml we can just do a apt update && apt upgrade -y. Some things are a little bit akward but BitBucket didn't had this, too: - FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary) - CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines https://gitlab.com/gitlab-org/gitlab-ce/issues/19455 https://gitlab.com/gitlab-org/gitlab-ce/issues/19455 - Artifacts API is limited to everything or nothing - CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw) - No Custom CSS (yeah our logo isn't 72px x 72px...) But then again BitBucket didn't had these things anyway so except the bug it's nothing that would've hold us back. Everytime you wanted a Feature for BitBucket, the guys said that there is/was an extension. How dare that costed a shitload of money which would even superseeded GitLab EE.

jobvandervoort 10y ago
Thank you for the awesome detailed feedback. Responded point by point below: > FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary) These are always hard choices to make for us. We wrote about these decisions here [0]. > CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines We're still young, but confident that we'll get there! CI/CD is a major focus for us and we're working really hard to improve it with every release. Love to get specific feature requests for things that we miss in comparison with Jenkins. Regarding the bug: I've pinged our PM on it. > Artifacts API is limited to everything or nothing Could you elaborate? I know we have numerous improvements planned, but I'm not sure about their prioritization. > CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw) Hm, could you write a feature proposal for this [1]? It sounds like a great improvement. > No Custom CSS (yeah our logo isn't 72px x 72px...) We're extremely hesitant to do this, as we make many changes between releases. This would break custom css with every upgrade, in turn resulting in a worse experience. I rather hear suggestions about specific parts in the interface that should be made customizable or suggestions about changes to the UI altogether. Although I'm not a fan of custom css, there is an issue to discuss this and I welcome your input there [2]. [0]: https://about.gitlab.com/2016/01/11/being-a-good-open-source-steward/ https://about.gitlab.com/2016/01/11/being-a-good-open-source... [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/new https://gitlab.com/gitlab-org/gitlab-ce/issues/new [2]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15635 https://gitlab.com/gitlab-org/gitlab-ce/issues/15635
- merb 10y ago
  Actually as already said even with the stuff mentioned here, it's really really a good project and we are happy. to [0] we've gone the CE route first since we are too small and too fast running that a EE makes sense yet (too good that you can switch between the two without any major drawbacks [http://docs.gitlab.com/ee/downgrade_ee_to_ce/README.html http://docs.gitlab.com/ee/downgrade_ee_to_ce/README.html] and [http://docs.gitlab.com/omnibus/update/README.html#from-community-edition-to-enterprise-edition http://docs.gitlab.com/omnibus/update/README.html#from-commu...] thats one of the major selling points, ease of use is really big in gitlab). but sitll every feature mentioned here wasn't in bitbucket so it's not like we've missing something, we've gained something while switching so we are probably whining on a really high level ;) Oh and thanks god for the easy backup stuff, which even works while running (which other products doesn't....)
  - jobvandervoort 10y ago
    Thanks merb!
zegerjan 10y ago
> - CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines Do you have more examples of workflows we are not supporting at all or well enough? > - Artifacts API is limited to everything or nothing Right you are, you might want to track this issue[1]. > - CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw) I don't fully comprehend what you mean, could you elaborate? [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/20603 https://gitlab.com/gitlab-org/gitlab-ce/issues/20603
- merb 10y ago
  Not supported Workflows: - JUnit XML or similar output reading to have a nice output what's broken / worked - Checkstyle output / pylint / tools for other languages - What I said about Artifacts - Artifacts are hard to Track I already wrote into [1] which would also be a good way - Actually external Triggers can't be conditional: https://gitlab.com/gitlab-org/gitlab-ce/issues/19826 https://gitlab.com/gitlab-org/gitlab-ce/issues/19826 So either that or have a way to name triggers which I opened here: https://gitlab.com/gitlab-org/gitlab-ce/issues/20574 https://gitlab.com/gitlab-org/gitlab-ce/issues/20574 And I guess these are the things my company does / did with jenkins. There is also another downside but we don't do that anymore: You can't push from CI to master branches, some people do tag and create builds with their CI / CD (which we also did) but now we just push a Tag to the Repo and the CI will be: '- only: tags' and catch that up. That's all stuff I can think of now which is probably not supported by most "simple" CI / CD Tools. I guess only the big one's have such a thing like TeamCity, Jenkins and Bamboo.

by merb 10y ago

jobvandervoort 10y ago

Thank you for the awesome detailed feedback. Responded point by point below: > FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary) These are always hard choices to make for us. We wrote about these decisions here [0]. > CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines We're still young, but confident that we'll get there! CI/CD is a major focus for us and we're working really hard to improve it with every release. Love to get specific feature requests for things that we miss in comparison with Jenkins. Regarding the bug: I've pinged our PM on it. > Artifacts API is limited to everything or nothing Could you elaborate? I know we have numerous improvements planned, but I'm not sure about their prioritization. > CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw) Hm, could you write a feature proposal for this [1]? It sounds like a great improvement. > No Custom CSS (yeah our logo isn't 72px x 72px...) We're extremely hesitant to do this, as we make many changes between releases. This would break custom css with every upgrade, in turn resulting in a worse experience. I rather hear suggestions about specific parts in the interface that should be made customizable or suggestions about changes to the UI altogether. Although I'm not a fan of custom css, there is an issue to discuss this and I welcome your input there [2]. [0]: https://about.gitlab.com/2016/01/11/being-a-good-open-source-steward/ https://about.gitlab.com/2016/01/11/being-a-good-open-source... [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/new https://gitlab.com/gitlab-org/gitlab-ce/issues/new [2]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15635 https://gitlab.com/gitlab-org/gitlab-ce/issues/15635

merb 10y ago
Actually as already said even with the stuff mentioned here, it's really really a good project and we are happy. to [0] we've gone the CE route first since we are too small and too fast running that a EE makes sense yet (too good that you can switch between the two without any major drawbacks [http://docs.gitlab.com/ee/downgrade_ee_to_ce/README.html http://docs.gitlab.com/ee/downgrade_ee_to_ce/README.html] and [http://docs.gitlab.com/omnibus/update/README.html#from-community-edition-to-enterprise-edition http://docs.gitlab.com/omnibus/update/README.html#from-commu...] thats one of the major selling points, ease of use is really big in gitlab). but sitll every feature mentioned here wasn't in bitbucket so it's not like we've missing something, we've gained something while switching so we are probably whining on a really high level ;) Oh and thanks god for the easy backup stuff, which even works while running (which other products doesn't....)
- jobvandervoort 10y ago
  Thanks merb!

zegerjan 10y ago

> - CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines Do you have more examples of workflows we are not supporting at all or well enough? > - Artifacts API is limited to everything or nothing Right you are, you might want to track this issue[1]. > - CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw) I don't fully comprehend what you mean, could you elaborate? [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/20603 https://gitlab.com/gitlab-org/gitlab-ce/issues/20603

merb 10y ago
Not supported Workflows: - JUnit XML or similar output reading to have a nice output what's broken / worked - Checkstyle output / pylint / tools for other languages - What I said about Artifacts - Artifacts are hard to Track I already wrote into [1] which would also be a good way - Actually external Triggers can't be conditional: https://gitlab.com/gitlab-org/gitlab-ce/issues/19826 https://gitlab.com/gitlab-org/gitlab-ce/issues/19826 So either that or have a way to name triggers which I opened here: https://gitlab.com/gitlab-org/gitlab-ce/issues/20574 https://gitlab.com/gitlab-org/gitlab-ce/issues/20574 And I guess these are the things my company does / did with jenkins. There is also another downside but we don't do that anymore: You can't push from CI to master branches, some people do tag and create builds with their CI / CD (which we also did) but now we just push a Tag to the Repo and the CI will be: '- only: tags' and catch that up. That's all stuff I can think of now which is probably not supported by most "simple" CI / CD Tools. I guess only the big one's have such a thing like TeamCity, Jenkins and Bamboo.