5 ms·

> nobody has _really_ thought about providing a great unified UX for all of this. Isn't the Stash-Jira-Bamboo-Confluence stack a unified UX for doing all of th

> nobody has _really_ thought about providing a great unified UX for all of this. Isn't the Stash-Jira-Bamboo-Confluence stack a unified UX for doing all of this (source control, pull requests, deployment, docs, issue tracker, build pipeline, etc)? It may not be a great UX, but can we at least give Atlassian credit from probably having thought about it having a great UX?

nathan_f77 10y ago
That's funny, because you're right, and Atlassian has an enormous head start. And it's hard to explain why I like GitLab so much more. I used the entire Atlassian suite for 3 years at my first web development gig, when I started over 7 years ago. I just have all these memories of things being ugly, slow, and hard to customize. Although I had a mostly positive experience with Confluence. Bamboo was just not nice to use. BitBucket does most of the same things, but it just didn't feel nice to use. Maybe it's the UI, or the dark blue theme. Maybe it's purely psychological, like GitHub was the place where all the cool developers hang out, and BitBucket is the corporate nerd who just wants to fit in so they give away all their private repos for free. So I dumped my private, personal stuff on BitBucket, until GitLab came along. And honestly, up until the last few months, I actually really disliked GitLab. I kind of saw them as just rip-offs who were blatantly copying GitHub, and stealing their customers. But then I realized that GitHub hasn't really done anything interesting for years and years, while GitLab is working on all these awesome features and integrating things that GitHub should have been doing years ago. So now my opinion is that GitHub had their chance, and they blew. GitLab is the new cool place to host your code.
- Snappy 10y ago
  Wow, thanks for the kind words. GitLab has grown a LOT in the last year or so.
- technomancy 10y ago
  > And it's hard to explain why I like GitLab so much more. In my case having the Atlassian all tools look the same seems to have backfired; every time I go to BitBucket it makes me think of Jira, which makes me cringe and wish I were on a different web site.
aalbertson 10y ago
All I can say is....L.O.L.... Go compare keyboard shortcuts between all these services and you'll quickly change your mind.
draw_down 10y ago
They're just so bad at making tools usable. I don't know why. Stash was SO frustrating when I had to use it at my last job.
user5994461 10y ago
And you can add the Jetbrains stack on top of that: Teamcity + Youtrack + upsource + IntelliJ. The jetbrains stack VS The atlassian stack. A long standing competition between the best tools in the world.
- snuxoll 10y ago
  We still use TFS at work for issue and code management (mainly due to inertia and it being included with our Visual Studio licenses) but TeamCity easily blows every other CI tool I've used out of the water - we love it and the sane pricing.
  - flukus 10y ago
    I like Team City, but a CI server should just be a tool to check out code and call your build scripts. The choice of CI shouldn't matter much.
    - user5994461 10y ago
      The CI choice is important. There are many features that must come from the CI: - Support downloading the code from various repo (GIT, SVN...) - Option to start build from scratch or keep the state from the previous build - Integrate with your user accounts (LDAP, Google Auth...) - Good and stable API [jenkins API is a complete mess] - Storing and retrieving build artifacts - Bisecting - Running batch of builds / parametrized builds - Graphing and statistics (build durations, build failures, ...) - Backup system for the configuration of the CI master (must be scriptable) - High availability: Either support a pair of CI master with active/passive, or support scaling horizontally with many active masters (this is critical for > 1000 dev companies with many many projects) - Build in monitoring in the CI master itself (e.g. manage the space taken by projects and artifacts) with a notifications when things are going critical. ...
      - flukus 10y ago
        > Support downloading the code from various repo (GIT, SVN...) Is there a CI server that can't handle this? Worst case you can do a checkout from the command line. > Option to start build from scratch or keep the state from the previous build This should be part of the build script. "make clean build" or "make build". >Integrate with your user accounts (LDAP, Google Auth...) Not sure whatthe case for this is, but the authorization can be passed to the build script anyway. > Good and stable API [jenkins API is a complete mess] What do you need the api for? > Storing and retrieving build artifacts Again, better off being a feature of the build script. > Bisecting This is a job for humans. >Running batch of builds / parametrized builds Doesn't every CI server have this? > Graphing and statistics (build durations, build failures, ...) This is really not important. > Backup system for the configuration of the CI master (must be scriptable) Why is this part of the CI server and not a general backup system? > High availability: Either support a pair of CI master with active/passive, or support scaling horizontally with many active masters (this is critical for > 1000 dev companies with many many projects) This really isn't important. The CI server being out for a few hours will not bring down the company. If you have that many projects then there is no problem with having multiple build servers. >Build in monitoring in the CI master itself (e.g. manage the space taken by projects and artifacts) with a notifications when things are going critical. Like the backups, this should be part of a general OS monitoring, no need to complicate the CI server.
spdustin 10y ago
If only they had applied that "forward thinking" to upgrades. It's one of the reasons we're leaving them behind. We use GitLab for both internal and client project code, including their runners to run limiting on code (for example) so web based edits/commits can be checked with the same rules we may run locally. Love it. We use GitLab wikis to replace Confluence (which had replaced Evernote because, well, I couldn't trust them any more). We sometimes use Gollum locally because sometimes a UI around editing pages is helpful, though I sure wish prose.io connected to GitLab. I'd also like to see GitLab switch to Kramdown for Markdown rendering (there's an issue open for that already) and actually use the Gollum gem to render the pages, so that we can use the various partials that Gollum supports when it's serving up a wiki. Once time tracking lands in GitLab, our (admittedly) basic usage of Jira can be replaced, since we're already using guest/reporter accounts for customers to report all issues on any custom dev project we do for them. We'd like to see that on-boarding process (for our clients who we intend to use Issues) go a little more smoothly, and I'm working on a written spec for proposed improvements, and I'm comfortable enough with their code base to take a whack at writing it. If it's not dev work (e.g. a general SharePoint support contract), we just use a new HelpScout mailbox with a custom email address for the client. That email address is just an alias that forwards to the primary HelpScout mailbox, where a workflow rule moves it to the client's specific HelpScout mailbox. Nice thing is that HelpScout's Slack trigger doesn't fire until after the email is moved, so notifications also go to the channel we use to discuss that customer's issues. If Mattermost got bundled with their hosted offering, that'd be killer. We're using their free hosted service, and so I'm reticent to ask for these sorts of changes by opening issues unless I want to at least attempt to contribute the code for it. I'm unsure how some of that would work out in their multi-tenant environment, but I still plan to dig into it. GitLab is good stuff. I've been deeply impressed by their agility and responsiveness to their customers. If anyone is on the fence, there's no cost to check out early all of their features.
- Snappy 10y ago
  > We're using their free hosted service, and so I'm reticent to ask for these sorts of changes by opening issues unless I want to at least attempt to contribute the code for it. Please feel free to open issues anyway. We love hearing directly from users and always want to improve the product, even if you don't pay for it or contribute code. :)

nathan_f77 10y ago

That's funny, because you're right, and Atlassian has an enormous head start. And it's hard to explain why I like GitLab so much more. I used the entire Atlassian suite for 3 years at my first web development gig, when I started over 7 years ago. I just have all these memories of things being ugly, slow, and hard to customize. Although I had a mostly positive experience with Confluence. Bamboo was just not nice to use. BitBucket does most of the same things, but it just didn't feel nice to use. Maybe it's the UI, or the dark blue theme. Maybe it's purely psychological, like GitHub was the place where all the cool developers hang out, and BitBucket is the corporate nerd who just wants to fit in so they give away all their private repos for free. So I dumped my private, personal stuff on BitBucket, until GitLab came along. And honestly, up until the last few months, I actually really disliked GitLab. I kind of saw them as just rip-offs who were blatantly copying GitHub, and stealing their customers. But then I realized that GitHub hasn't really done anything interesting for years and years, while GitLab is working on all these awesome features and integrating things that GitHub should have been doing years ago. So now my opinion is that GitHub had their chance, and they blew. GitLab is the new cool place to host your code.

Snappy 10y ago
Wow, thanks for the kind words. GitLab has grown a LOT in the last year or so.
technomancy 10y ago
> And it's hard to explain why I like GitLab so much more. In my case having the Atlassian all tools look the same seems to have backfired; every time I go to BitBucket it makes me think of Jira, which makes me cringe and wish I were on a different web site.

aalbertson 10y ago

All I can say is....L.O.L.... Go compare keyboard shortcuts between all these services and you'll quickly change your mind.

draw_down 10y ago

They're just so bad at making tools usable. I don't know why. Stash was SO frustrating when I had to use it at my last job.

user5994461 10y ago

And you can add the Jetbrains stack on top of that: Teamcity + Youtrack + upsource + IntelliJ. The jetbrains stack VS The atlassian stack. A long standing competition between the best tools in the world.

snuxoll 10y ago
We still use TFS at work for issue and code management (mainly due to inertia and it being included with our Visual Studio licenses) but TeamCity easily blows every other CI tool I've used out of the water - we love it and the sane pricing.
- flukus 10y ago
  I like Team City, but a CI server should just be a tool to check out code and call your build scripts. The choice of CI shouldn't matter much.
  - user5994461 10y ago
    The CI choice is important. There are many features that must come from the CI: - Support downloading the code from various repo (GIT, SVN...) - Option to start build from scratch or keep the state from the previous build - Integrate with your user accounts (LDAP, Google Auth...) - Good and stable API [jenkins API is a complete mess] - Storing and retrieving build artifacts - Bisecting - Running batch of builds / parametrized builds - Graphing and statistics (build durations, build failures, ...) - Backup system for the configuration of the CI master (must be scriptable) - High availability: Either support a pair of CI master with active/passive, or support scaling horizontally with many active masters (this is critical for > 1000 dev companies with many many projects) - Build in monitoring in the CI master itself (e.g. manage the space taken by projects and artifacts) with a notifications when things are going critical. ...
    - flukus 10y ago
      > Support downloading the code from various repo (GIT, SVN...) Is there a CI server that can't handle this? Worst case you can do a checkout from the command line. > Option to start build from scratch or keep the state from the previous build This should be part of the build script. "make clean build" or "make build". >Integrate with your user accounts (LDAP, Google Auth...) Not sure whatthe case for this is, but the authorization can be passed to the build script anyway. > Good and stable API [jenkins API is a complete mess] What do you need the api for? > Storing and retrieving build artifacts Again, better off being a feature of the build script. > Bisecting This is a job for humans. >Running batch of builds / parametrized builds Doesn't every CI server have this? > Graphing and statistics (build durations, build failures, ...) This is really not important. > Backup system for the configuration of the CI master (must be scriptable) Why is this part of the CI server and not a general backup system? > High availability: Either support a pair of CI master with active/passive, or support scaling horizontally with many active masters (this is critical for > 1000 dev companies with many many projects) This really isn't important. The CI server being out for a few hours will not bring down the company. If you have that many projects then there is no problem with having multiple build servers. >Build in monitoring in the CI master itself (e.g. manage the space taken by projects and artifacts) with a notifications when things are going critical. Like the backups, this should be part of a general OS monitoring, no need to complicate the CI server.

spdustin 10y ago

If only they had applied that "forward thinking" to upgrades. It's one of the reasons we're leaving them behind. We use GitLab for both internal and client project code, including their runners to run limiting on code (for example) so web based edits/commits can be checked with the same rules we may run locally. Love it. We use GitLab wikis to replace Confluence (which had replaced Evernote because, well, I couldn't trust them any more). We sometimes use Gollum locally because sometimes a UI around editing pages is helpful, though I sure wish prose.io connected to GitLab. I'd also like to see GitLab switch to Kramdown for Markdown rendering (there's an issue open for that already) and actually use the Gollum gem to render the pages, so that we can use the various partials that Gollum supports when it's serving up a wiki. Once time tracking lands in GitLab, our (admittedly) basic usage of Jira can be replaced, since we're already using guest/reporter accounts for customers to report all issues on any custom dev project we do for them. We'd like to see that on-boarding process (for our clients who we intend to use Issues) go a little more smoothly, and I'm working on a written spec for proposed improvements, and I'm comfortable enough with their code base to take a whack at writing it. If it's not dev work (e.g. a general SharePoint support contract), we just use a new HelpScout mailbox with a custom email address for the client. That email address is just an alias that forwards to the primary HelpScout mailbox, where a workflow rule moves it to the client's specific HelpScout mailbox. Nice thing is that HelpScout's Slack trigger doesn't fire until after the email is moved, so notifications also go to the channel we use to discuss that customer's issues. If Mattermost got bundled with their hosted offering, that'd be killer. We're using their free hosted service, and so I'm reticent to ask for these sorts of changes by opening issues unless I want to at least attempt to contribute the code for it. I'm unsure how some of that would work out in their multi-tenant environment, but I still plan to dig into it. GitLab is good stuff. I've been deeply impressed by their agility and responsiveness to their customers. If anyone is on the fence, there's no cost to check out early all of their features.

Snappy 10y ago
> We're using their free hosted service, and so I'm reticent to ask for these sorts of changes by opening issues unless I want to at least attempt to contribute the code for it. Please feel free to open issues anyway. We love hearing directly from users and always want to improve the product, even if you don't pay for it or contribute code. :)