What’s Next for Gitlab CI: Auto DevOps

To see that the UI design is bad at times, take the design of merge requests and issues for example.

On Github you can easily see what happens, comments are surrounded by a black border, the name of the comment author and the date are clearly visible and have a different background color from the comment text. Actions like closing and re-opening are distinctly different from comments and are color coded (green -> re-opened, red -> closed, purple -> merged). Emoticons are part of the comment box and don't visually drift into the next one.

Gitlab on the other hand separates comments by a thin (1px) light-grey line that is hardly visible on low contrast monitors like TN displays. Closing and re-opening is also displayed as a light-grey icon on a white background. The author's name has the same color as the comment text, with the date being, again, light-grey. Nothing keeps the contents of a comment together, it's all just text on a white background. The emoticons are just floating around the comments, with the same margin to the next comment as to the comment they are belonging to. So you have to know that emoticons are always below a comment.

Github's design is far, far superior to Gitlab's design because it allows skimming instead of concentrating on finding where each comment begins and ends.

Maybe for paid solutions. But I'd guess if you take the free version of Gitlab into account, it is probably the dominant self-hosted Git solution.

I don't agree with your point on the 'review-app' pattern. While I agree it would be more work to create a 'review cluster' (I assume you mean app + related services + some test data), this is the kind of effort I think quickly makes you do something a smarter way once you've felt the pain.

Also, companies I've worked at in the past (when sufficiently big) have had "playground" AWS accounts that had a fixed cost for daily all-you-can-use resources. I'd like to think that if you're big enough to think you need >2/3 supporting services to come up with your app, maybe you already have enough traction for that kind of cloud playground account?

I can only speak definitively for myself, but most apps I have built are generally 1 app instance, 1 DB and _maybe_ 1 service for caching. Thinking about how to make these easier to spin up (which includes making sure it's easy for me to make a close-to-production environment as quick as possible), has benefited me, despite initial pain.

Also, if cost is the angle, there are tens of things companies could do, but don't that could bring down cost. Outside of "have more performance-minded developers", "add more computers" is often the cheapest option a company has as far as increasing performance (hence the whole rise of horizontal scalability right?).

I agree that Gitlab should focus on user experience (I'm not sure what you were referring to by "Git hosting"), but I am happy that they've decided to add this CI/CD (and issue boards, and CI), in ONE place.

Gitlab doesn't spout that rhetoric, and neither am I. What I intended was a little more nuanced, I will restate, this time (hopefully) more clearly:

Bad UI on your git hosting tool is very likely not what's holding back your org from delivering faster. It's more likely things like not automating your builds/pipelines/deployment.

Maybe you're at a company that's already doing this properly, you've got Github/Bitbucket Server/whatever set up, with Jenkins Integration, Spinnaker, Quay.io, and you're humming along. While I could make a case for why Gitlab might still benefit you in that environment, it's more likely that at that point, you don't even need it. For every org that is NOT there yet, I think Gitlab offers a benefit -- not thinking about how to get all those other things working.

Maybe where I am on this trade-off is just not the right side, but I see it like this: I prefer a tool that hosts code, automatically tests and deploys a testing instance of the application to host my code than a tool that hosts code but requires more setup to offer that kind of value, even if that second tool has better UI and is seconds or even minutes faster.

The best GUI is the one I don't even have to use -- and I think Gitlab is doing it's best to head towards that, by automate more of the development process for me -- I don't see Github doing this (though they're obviously not against it, they just don't seem to be innovating in this area)

I really like the core of gitlab. It's a really good git hosting system that is easy to maintain and work with. My self hosted instance has broken only twice in the last 1.5 years and it was always because of an upgrade and it was always easily fixed.

But now i have to say i'm afraid gitlab is getting bloated. Why not keep the core product as a seperate thing from things like CI? a simple plugin style system would be enough for it to not feel like bloat but feel like extra options.