> 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?
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.
> 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.
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.
> 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. :)
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.
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.
> 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.
>> 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.
It's common NOW. It's been a problem for a very long time. The transition to the git era took a while and didn't happen smoothly.
I didn't check, but there may be some of the SaaS services being bound to specific repo services.
>> 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".
A script can't "rm -rf ." at the start of the build or it destroys itself ;)
A script could "rm -rf ." at the end of the build... except when the build fails midway, leaving the machine in an inconsistent state.
>>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.
I am not talking about build. I am talking about people signing in to the web ui with some sort of user accounts.
>> Good and stable API [jenkins API is a complete mess]
>What do you need the api for?
To add/remove slaves programmatically. To trigger builds and get build status. Among other things.
>> Storing and retrieving build artifacts
>Again, better off being a feature of the build script.
The CI SHOULD have a feature to store artifacts or upload to ftp/ssh/s3. (other)
There is no excuse for not supporting common use case. It's better to have CI's dev program it right once, than having one million user each baking their own buggy scripts.
>> Bisecting
>This is a job for humans.
WTF. The job of a human is not to click 20 times through the interface only to enter the git hash of 20 commits.
Just gimme a button "build last N commits" or "build commit between X date and Y date"
>>Running batch of builds / parametrized builds (had matrix build in mind specifically)
>Doesn't every CI server have this?
As a matter of fact: No, they don't.
(I was also surprised to discover that in the wild).
>> Graphing and statistics (build durations, build failures, ...)
>This is really not important.
It is important. We NEED to check the evolution of the build duration.
>> 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?
It is the responsibility of one's system that the system is backable.
If all the configuration of the CI is a "conf.xml". It's okay, I can just copy that file.
If all CI master is a mess of thousands of directories and files, where the master node configuration and the build configurations and the past build info are intertwined. I am forced to backup everything together, which may be 100 GB of data.
If the past builds and current configurations are referencing each other with unique GUID and numbers, in a way that ANY file missing might cause the jenkins server to not boot... I am fucked, especially so because there is no way to backup atomically 100 GB of data across 100000 files and directories while builds are running.
> 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.
Given your arguments of all things being useless. You seem to be working in a very small company or not have worked professionally at all.
Please try to envision a real company: When the CI system breaks, there are 100 people who are interrupted and they will be partially unable to work until it is fixed.
By The Way: It's easier to maintain and manage one big system. By splitting one CI pipeline into 10 CI, you just created 9 SPOF and you just increased the failure rate dramatically.
>>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
It is the responsibility of one's system that the system is reliable.
First) CI servers have disk space issues. I expect a sensible way to find out what projects/builds are taking and the ability to clean it up. [a monitoring system will give full disk alert, it doesn't understand the CI internal organization]
Second) If the dev are not retarded, they can put a notification for everyone to see when the disk is at 99% instead of writing the last % and crashing... only to never reboot again because it corrupted itself in the process.
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?