9 ms·

What’s Next for Gitlab CI: Auto DevOps

135 points by hardwaresofton 9y ago

hardwaresofton 9y ago
OP here, just to note - I'm not an employee or affiliated with Gitlab in any way (outside of considering working for them once) -- just a rabid fan. I've been at companies where I've tried (and failed) to convince other developers/higher ups that something like automatically creating an instance of an app based on the feature branch (what Gitlab/others are calling a "review-app"), is the best way to test individual features with high velocity (of course, this requires one more integration level test in the staging environment to make sure everything works together well). I'm impressed/awed/grateful that Gitlab is pulling these features into their 100% open source solution. The most common complaints against gitlab are: - Gitlab's UI is bad-ish (this is what made me consider going to work there/contributing and helping fix that) - Gitlab is slow And I think they're dumb. If you think UI on your code hosting tool and slow file operations (on the order of minutes, not hours) to be what would slow their org down, instead of the fact that you haven't automated things that Gitlab wants to automate for free for you (like test deployments actual deployments, build steps), in one coherent place (no juggling github, jenkins, jira, whatever else) then I think you're wrong.
- siliconc0w 9y ago
  The UI is bad period. 85% navigation on a normal laptop display (1080). There are layers and layers of menus and submenus which could easily be combined and make little sense. And i'm not even someone with a 'design aesthetic'. The 'review-app' pattern is interesting but doesn't scale for more complicated apps. You'd need to create a 'review cluster' for every branch which quickly becomes untenable. It's usually not lack of automation but cost driving down the number of non-prod environments. I'm actually a big fan of Gitlab but they should probably focus on user experience and Git hosting and let the other sizable number of products/projects which already exist focus on deployment. Spinnaker, for example, is probably what I'd recommend companies adopt for CD if they're looking to go in that direction.
  - hardwaresofton 9y ago
    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.
  - cmatija 9y ago
    Sorry to hear you're displeased with our UI. We're always looking to improve our UI and UX as much as we can. There's currently a navigation overhaul planned [1]. If you have any other specific suggestions complaints about the UI we'd love to hear about it, you can even open an issue about it yourself [2] [1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
    - CameronBanga 9y ago
      Reporting UI issues is a bad experience on GitLab in and of itself. The move to a hamburger menu saw significant outcry, and was followed by one of the more popular tickets I've ever seen on GitLab asking for the ability to restore the menu pin feature. Every complaint and criticism was basically replied with "Nah, we're keeping it.", because the new hamburger menu had gone through "design testing". If you're looking to improve UI/UX, the design team should look through those tickets and learn how to listen when so many users are speaking up against a redesign.
- izolate 9y ago
  Bad-ish? Try horrible. GitHub has raised the bar too high for Gitlab to spout the tired developer rhetoric that UI/UX doesn't matter.
  - hardwaresofton 9y ago
    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)
    - wolco 9y ago
      The issue for them is those who don't care about UI are the type who can setup and run there own version of a similiar product. The crowd that would benefit the most has a modern saas mindset.. simple, fast ui. less clutter..
  - cmatija 9y ago
    Sorry to hear you think it's horrible. We're working very hard on making it a pleasant and enjoyable experience. We're currently planning a navigation overhaul [1]. You can also check out a list of all current UX issues in [2]. And, any specific feedback is greatly appreciated, you can open an issue about anything at [3]. [1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=UX https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... [3] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
- flipp3r 9y ago
  Gitlab's UI is absolutely awful and incredibly slow. Would you say the same for other tools, like email, or your IDE or editor? They literally copied every functionality and UI of GitHub when they started out, and the only difference at the time was that Gitlab was a slower version of Github. I'm glad you can self-host it, and that they're open source, they've got that going. But if GitHub would ever open source their tool, it's over.
  - hardwaresofton 9y ago
    A few things: I think you're using too much hyperbole -- it's all relative, and if you think Gitlab's UI is the bottom of the pile, you haven't used enough software and truly seen what bad UI looks like. I'm not saying UI doesn't matter, I'm just saying what they have is workable (and can get better, and they've expressed that they care to improve it). Email, IDE, Editors are not the same as your code hosting, testing, deployment tool, that's a false equivalency. Maybe I must be the only one that is OK waiting 20 seconds for a merge request to complete. I don't think it is reasonable to hold the fact that they copied/mimiced Github's functionality or UI when they started out against them. Society couldn't move forward if people didn't recycle and improve ideas. As far as the differences go, while what you said might have been true, it's not these days. Also, you haven't addressed the point that Gitlab offers a shorter path to Doing It Right (tm) (albeit a pretty subjective definition of "right") than Github does.
    - u801e 9y ago
      > Email, IDE, Editors are not the same as your code hosting, testing, deployment tool Why should hosting, testing, and deployment be handled by the same tool (as opposed to tools that handle each need individually)?
      - hardwaresofton 9y ago
        That's a good question -- and of course, the answer is it depends. Having small focused tools is great, but that's only when the substrate/platform that lets you combine them is suuuuper good/standardized/well-designed. `cat file.txt | sort | uniq` is excellent, but I think a lot of the ergonomics of that kind of small/focused tool reusability is due to the super low friction of using pipe, and how well STDIN, STDOUT, and STDERR work behind the scenes. This kind of falls apart when you try and string together web services. In my opinion, Gitlab's inclusion of so many parts of the process is good because it saves you from having to manage all the other tools, and it gives you answers for the complete process (where it's possible you could get painted into a corner depending on which focused tools you picked to do some pieces of the process, and have to write your own glue or go on a long search).
- jmiserez 9y ago
  I work with self-hosted Gitlab daily and I’ve never thought the UI was bad or slow. In fact, I think it works pretty well. To the other commenters: Do you have any examples? Also, I’m excited about auto deployment. The less tools one needs to get software shipped, the better.
  - foepys 9y ago
    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.
    - jamedjo 9y ago
      This comment reminded me to create issues for reducing clutter on the MR page [0], and expanding multiple resolved discussions [1] [0] https://gitlab.com/gitlab-org/gitlab-ce/issues/34814 https://gitlab.com/gitlab-org/gitlab-ce/issues/34814 [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/34813 https://gitlab.com/gitlab-org/gitlab-ce/issues/34813
    - cmatija 9y ago
      We're working on lots of UX improvements. There's a navigation overhaul planned [1], you can also check out a list of all current UX issues with [2]. As always, community feedback is something we always welcome wholeheartedly [3] [1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=UX https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... [3] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
- cyphar 9y ago
  > Gitlab's UI is bad-ish (this is what made me consider going to work there/contributing and helping fix that) If you'd asked me a year ago, I would've said some very harsh things at this point. But I just went to find examples of the issues I had a year ago (and we still have on our own internal GitLab instances), and it looks like most of them have been resolved. There's still weird duplication (why is there still a "Repository" tab when you can see the repo on the front page) but that's all just small warts that don't matter as much. I think GitLab still suffers from a weird workflow, but it's much better now than it was in the past. > Gitlab is slow. The reason why this is an issue is not the fault of the technology imo, but rather a fault of the marketing and community. GitLab is not meant to usurp https://github.com https://github.com. It's meant to be a viable alternative to GitHub EE. Unfortunately, there appears to be a split-brain in the community. GitLab themselves are saying that https://gitlab.com https://gitlab.com has scaling issues that they are working on resolving, but that self-hosting will not have these issues unless you're planning on running at the same scale as them. But the community appears to want more people to swap away from https://github.com https://github.com to https://gitlab.com https://gitlab.com (that's the impression I get). By doing that, you've now said "any comparisons between https://github.com https://github.com and https://gitlab.com https://gitlab.com are entirely valid because we're advertising them in the same capacity". That's selling yourselves short. If GitLab had decided to go for a federated model, then this sort of marketing problem wouldn't be nearly as much of an issue (you would run into the Mastodon effect, where everyone joins the "official server" -- but if you made it possible to migrate the users, permissions, issues and state of the repo then it wouldn't be a long-term concern). They didn't, and that's fine, but that means that marketing https://gitlab.com https://gitlab.com as a replacement for https://github.com https://github.com is going to just cause problems.
flipp3r 9y ago
"Gitlab dominates self-hosted git" Dont you mean, Gitlab, "2/3 of people surveyed by Bitrise, a CI service you may have never heard of, which is free, are using Gitlab, which is also free"
- philtar 9y ago
  The two statements are not mutually exclusive.
  - madez 9y ago
    Neither implies the latter the former.
- hardwaresofton 9y ago
  I regret editorializing that fact from the article into the submission title. I should have just titled this submission "Gitlab's next step: Auto Deploy"
dehef 9y ago
I always use http://gitolite.com http://gitolite.com, thats enough. nb: I dont see the point of the graph about numbers of questions on SO. A high level of questions = A lot of problem, no :)?
- usernam 9y ago
  Couldn't agree more. Gitolite is enough for most use cases, and for technical users which often use other tools there's no need for a web interface (or anything beyond gitweb anyway). We use it in combination with BugsEverywhere for issue tracking, with the added advantage that bugs are tracked per-branch. You can work offline without issues. The major complaint with this system is the disconnect for users to report issues. BE includes a web frontend, but it's not great. We use mantis as a general tracker, but still keep detailed bug tracking in the VCS with BE.
- raziel2p 9y ago
  I really like gitolite, except how you need to add users and SSH keys through a git repository. I'd prefer just plain configuration files that I could manage with my configuration manager.
  - lazarus101 9y ago
    I've wasted so many hours trying to convince Windows user that they don't need any passwords for gitolite, they just need to check that Pageant is running and has the right key loaded :D
- cat199 9y ago
  gitolite + redmine = sweetness.
- lazarus101 9y ago
  Yep, gitolite is awesome, it's so lightweight you can use pretty much any leftover PC to host repos for an entire company. I also use cgit for a fast and easy git web interface and ReviewBoard for code reviews. If I remember correctly gitlab initially started as a frontend for gitolite.
kondro 9y ago
Pretty sure both GitHub Enterprise and BitBucket Server are the dominant self-hosted Git solutions.
- tlo 9y ago
  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.
- Sir_Substance 9y ago
  Interesting statement. Gitlab provided a datasource. You've got a better one showing your counterpoint, I take it?
- cyphar 9y ago
  As mentioned in TFA, that was based on this source[1] which surveyed what "app developers" used. If you have alternative statistics, I'd be happy to see them, but GitLab did provide a source for their claim. [1]: http://blog.bitrise.io/2017/01/27/state-of-app-development-in-2016.html#self-hosted http://blog.bitrise.io/2017/01/27/state-of-app-development-i...
- throwaway91111 9y ago
  You're directly contradicting the article. Got any evidence?
bartvanH 9y ago
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.
- cmatija 9y ago
  GitLab is envisioned as a platform for the full SDLC - from idea to production [1][2]. If you don't want to use the CI, it shouldn't get in your way. We'd love to hear any specific suggestions you might have, since we're always looking to improve. You can open an issue about them in [3] if you want. [1] - https://about.gitlab.com/handbook/product/i2p-demo/ https://about.gitlab.com/handbook/product/i2p-demo/ [2] - https://about.gitlab.com/direction/#scope https://about.gitlab.com/direction/#scope [3] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
  - mikepurvis 9y ago
    As GitLab user, I think the concern for me is split focus. For everywhere there's a tightly integrated built-in tool (issues, CI, container registry, etc), there also needs to be a separate, parallel effort to create, maintain, and document a sufficiently rich plugin interface that a third party can create a similarly tightly integrated experience when plugging in something external. Basically, they build the hooks but aren't dogfooding any of it, since their own integrations don't have to. And speaking from the perspective of someone using GitLab with Jira and Jenkins, it just isn't the same. Is that necessarily because of problems with the interface or is it just those specific plugins? I don't actually know.
    - brodock 9y ago
      GitLab CI started as a separate project, but team saw more benefits from integrating into a single product as it's much easier to provide tightly integration without the overhead of communication and APIs. There are places in the workflow that can't just support a hook for an external integration. While CI is integrated, it does not force you to use it, and there are ways to integrate with external solutions. While CI is part of the same product, you don't run the tests in the same machine, so you still need to provide the workers in additional ones or use the autoscalling mechanisms and have it bootstrap machines in the cloud as needed. So what I mean here is that while it is part of the product, it's mostly the "frontend" and the "APIs", the heavyload part of running it is totally optional.
deleted 9y ago
[deleted]
calafrax 9y ago
Gitlab is great. It took 5 minutes to install and has run flawlessly since. I was blown away by how complete, fully featured, and easy to use it is for a free product.
- Snappy 9y ago
  That's great to hear; thanks for the feedback!
willvarfar 9y ago
I would imagine that git dominates self-hosted git. I just have bare repos on servers I can ssh into. End of problem.
- wonko1 9y ago
  Of the 2 employers I've had who self-hosted, they both did this. I've also done this when self hosting, it's super easy. I guess there are probably no surveys of this though...
  - corobo 9y ago
    It's super easy for you. I tried to set this up but it's such a pain in the backside to tell people how to pull the latest code. Ended up with Gitlab and haven't looked back. I didn't even realise Gitlab doesn't have auto-deploy yet.. We set up a .gitlab-ci.yml script that deploys the code.
    - deleted 9y ago
      [deleted]
- pizza234 9y ago
  Storage (/infrastructure) is only a small part of the GitHub/GitLab functionality; with a bare repos one solves only one problem of many :-)
- deleted 9y ago
  [deleted]
- dmytrish 9y ago
  For personal use, indeed, just use an ssh remote + gitweb interface with basic authentication and that's it. For organizations it makes sense to have something more featureful.
  - u801e 9y ago
    For CI, you could have a git hook that could trigger a Jenkins build. For code review, you could use a tool like gerrit or phabricator or even set up an email list to send patch sets. What other features do Gitlab, Github, or Bitbucket have that wouldn't be covered by that type of setup?
anomie31 9y ago
Huh, I thought gogs and its forks dominated self hosted git, because it's just so easy to set up and use.
jpkeisala 9y ago
Does Gitlab have equivalent for Github Team account (5 users)?
- cmatija 9y ago
  We have free private repositories for all users and you can organize users into groups. Is this what you're looking for? If not, could you provide more context into what you're looking for?
knownothing 9y ago
"Gitlab dominates" 5% of the hosted market vs 95% of the SaaS market. And their reported popularity is based on data from a single CI company. This is further skewed since it's one of a few CI tools that actually supports Gitlab as an OAuth provider. There's no way this claim would stand up to any scrutiny or more data-gathering. It's just marketing fluff. EDIT: More on what upset me about this claim. First, we have no idea of what the composition of the 10,000 applications Bitrise surveyed are like. There could be a single company that uses Gitlab to test thousands of applications that completely invalidate this result. Second, this insults my (and every other competent readers') intelligence. This is badly done marketing. And their audience is developers. So they know they're misleading us but I guess they don't care.
- zxcmx 9y ago
  Stats don't make much sense. Self hosted bitbucket is huge. I've worked for Atlassian companies lately but none of their crap calls out to the Internet and tells the mothership what they're up to. Well I guess they do. But not in a way that other people can tell. Totally not an Atlassian shill (often I wish we had gitlab) but their stuff works self hosted real well. There's no way a third party could know what the numbers are, because when you use software which doesn't sell you out, well, you're not sold out.
wickchuck 9y ago
We've been on Gitlab since version 5 and for the most part it's been a pleasure to work with. The omnibus version has made things way easier to install/upgrade, so not sure what the fluff is about being hard to maintain. The UI is adequate and they are working on improvements to smooth out the rough edges a bit. Looking forward to the improvements and new features to come. Just wanted to post something positive instead of the nit picky hate I've been seeing lately about Gitlab...
jancsika 9y ago
For some reason, different parts of the Gitlab CI software expect different names for the runner binary-- possible names are gitlab-ci-multi-runner and gitlab-runner. If you set up a runner in a VM and want to upload artifacts, for some reason Gitlab CI requires you to install gitlab-ci-multi-runner on the VM guest (even though it is the host that is actually the runner). But when you do that, you have to actually go through the entire build process before seeing a non-terminal error that gitlab "couldn't find gitlab-runner". So now you have to go in on the VM guest, manually create a symlink from gitlab-ci-multi-runner to gitlab-runner, take a new snapshot of the VM state, and artifact upload will now work. I say "non-terminal" above because a failure to upload the artifact doesn't fail the build. So you can be looking at all checkmarks for everything in your pipeline and have no idea for which of those jobs you actually got artifacts. Also, every once in awhile I'll get failed builds where there is nothing at all in the build log. Typically, clicking "Retry" will successfully start a new build and complete successfully. Also, there is no way to specify to gitlab to keep only the last N artifacts. On the positive front, I finally figured out a way to set up an ssh server from within the msys2 environment in Windows, which requires no development whatsoever on the gitlab-ci infrastructure. That means gitlab-ci will ssh into msys2 on the runner, giving me a POSIX-y build environment on all my platforms. So that's nice. Sorry if this sounds overly negative and like a poor substitute for actually filing bugs. But the last time I worked on fixing a bug it took months for the maintainer just to click a button. This seems to be the only place I get timely response.
- bikebilly 9y ago
  Thanks for your feedback, we're seriously considering all the input from the community, wherever it is coming from. Talking about artifacts retention policy, we actually support defining an expiration date and we're also considering to add a maximum number in the future. You can find discussions about this topic in https://gitlab.com/gitlab-org/gitlab-ce/issues/23777 https://gitlab.com/gitlab-org/gitlab-ce/issues/23777 and https://gitlab.com/gitlab-org/gitlab-ce/issues/19208 https://gitlab.com/gitlab-org/gitlab-ce/issues/19208: in these issues there are also problems and consideration about having this feature implemented. Feel free to jump in and push your ideas!
Top19 9y ago
I really like Gitlab. It allows you to organize your repos, and do things like nesting them in categories. Why Github won't add this feature is beyond my understanding, and I really appreciate Gitlab stepping up and adding this into their platform. They also have a great system for migrating your repos over from Github.
- claytonjy 9y ago
  This! I'm at a small consulting shop (< 5 ppl), so it's really, really nice to have one subgroup per client; I'd hate having pages and pages of "client1-project1", "client1-project2", ... in a Github setup.
throwaway91111 9y ago
You know, this feature looks really cool, but the branding "Auto DevOps" seems like word-cloud clickbait and does not actually describe any distinguishing characteristics of the feature. DevOps is already a fuzzy area; what is Auto DevOps? It's at least another order of magnitude of semantic ambiguity.
- alchemism 9y ago
  The origin of "Auto DevOps" does seem to be a product branding creation: https://gitlab.com/gitlab-org/gitlab-ee/issues/2517 https://gitlab.com/gitlab-org/gitlab-ee/issues/2517
  - throwaway91111 9y ago
    That issue should have basically been in the press release; it's a lot clearer when they dump the branding and focus on actual concrete features they provide.
    - Snappy 9y ago
      Thanks for the feedback. Maybe next time we talk about it, we'll be more clear about the features.
juiyout 9y ago
I can no longer imagine using a CI system without job scripts committed. Could someone let me know why jenkins is still more popular?

OP here, just to note - I'm not an employee or affiliated with Gitlab in any way (outside of considering working for them once) -- just a rabid fan. I've been at companies where I've tried (and failed) to convince other developers/higher ups that something like automatically creating an instance of an app based on the feature branch (what Gitlab/others are calling a "review-app"), is the best way to test individual features with high velocity (of course, this requires one more integration level test in the staging environment to make sure everything works together well). I'm impressed/awed/grateful that Gitlab is pulling these features into their 100% open source solution. The most common complaints against gitlab are: - Gitlab's UI is bad-ish (this is what made me consider going to work there/contributing and helping fix that) - Gitlab is slow And I think they're dumb. If you think UI on your code hosting tool and slow file operations (on the order of minutes, not hours) to be what would slow their org down, instead of the fact that you haven't automated things that Gitlab wants to automate for free for you (like test deployments actual deployments, build steps), in one coherent place (no juggling github, jenkins, jira, whatever else) then I think you're wrong.

siliconc0w 9y ago
The UI is bad period. 85% navigation on a normal laptop display (1080). There are layers and layers of menus and submenus which could easily be combined and make little sense. And i'm not even someone with a 'design aesthetic'. The 'review-app' pattern is interesting but doesn't scale for more complicated apps. You'd need to create a 'review cluster' for every branch which quickly becomes untenable. It's usually not lack of automation but cost driving down the number of non-prod environments. I'm actually a big fan of Gitlab but they should probably focus on user experience and Git hosting and let the other sizable number of products/projects which already exist focus on deployment. Spinnaker, for example, is probably what I'd recommend companies adopt for CD if they're looking to go in that direction.
- hardwaresofton 9y ago
  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.
- cmatija 9y ago
  Sorry to hear you're displeased with our UI. We're always looking to improve our UI and UX as much as we can. There's currently a navigation overhaul planned [1]. If you have any other specific suggestions complaints about the UI we'd love to hear about it, you can even open an issue about it yourself [2] [1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
  - CameronBanga 9y ago
    Reporting UI issues is a bad experience on GitLab in and of itself. The move to a hamburger menu saw significant outcry, and was followed by one of the more popular tickets I've ever seen on GitLab asking for the ability to restore the menu pin feature. Every complaint and criticism was basically replied with "Nah, we're keeping it.", because the new hamburger menu had gone through "design testing". If you're looking to improve UI/UX, the design team should look through those tickets and learn how to listen when so many users are speaking up against a redesign.
izolate 9y ago
Bad-ish? Try horrible. GitHub has raised the bar too high for Gitlab to spout the tired developer rhetoric that UI/UX doesn't matter.
- hardwaresofton 9y ago
  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)
  - wolco 9y ago
    The issue for them is those who don't care about UI are the type who can setup and run there own version of a similiar product. The crowd that would benefit the most has a modern saas mindset.. simple, fast ui. less clutter..
- cmatija 9y ago
  Sorry to hear you think it's horrible. We're working very hard on making it a pleasant and enjoyable experience. We're currently planning a navigation overhaul [1]. You can also check out a list of all current UX issues in [2]. And, any specific feedback is greatly appreciated, you can open an issue about anything at [3]. [1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=UX https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... [3] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
flipp3r 9y ago
Gitlab's UI is absolutely awful and incredibly slow. Would you say the same for other tools, like email, or your IDE or editor? They literally copied every functionality and UI of GitHub when they started out, and the only difference at the time was that Gitlab was a slower version of Github. I'm glad you can self-host it, and that they're open source, they've got that going. But if GitHub would ever open source their tool, it's over.
- hardwaresofton 9y ago
  A few things: I think you're using too much hyperbole -- it's all relative, and if you think Gitlab's UI is the bottom of the pile, you haven't used enough software and truly seen what bad UI looks like. I'm not saying UI doesn't matter, I'm just saying what they have is workable (and can get better, and they've expressed that they care to improve it). Email, IDE, Editors are not the same as your code hosting, testing, deployment tool, that's a false equivalency. Maybe I must be the only one that is OK waiting 20 seconds for a merge request to complete. I don't think it is reasonable to hold the fact that they copied/mimiced Github's functionality or UI when they started out against them. Society couldn't move forward if people didn't recycle and improve ideas. As far as the differences go, while what you said might have been true, it's not these days. Also, you haven't addressed the point that Gitlab offers a shorter path to Doing It Right (tm) (albeit a pretty subjective definition of "right") than Github does.
  - u801e 9y ago
    > Email, IDE, Editors are not the same as your code hosting, testing, deployment tool Why should hosting, testing, and deployment be handled by the same tool (as opposed to tools that handle each need individually)?
    - hardwaresofton 9y ago
      That's a good question -- and of course, the answer is it depends. Having small focused tools is great, but that's only when the substrate/platform that lets you combine them is suuuuper good/standardized/well-designed. `cat file.txt | sort | uniq` is excellent, but I think a lot of the ergonomics of that kind of small/focused tool reusability is due to the super low friction of using pipe, and how well STDIN, STDOUT, and STDERR work behind the scenes. This kind of falls apart when you try and string together web services. In my opinion, Gitlab's inclusion of so many parts of the process is good because it saves you from having to manage all the other tools, and it gives you answers for the complete process (where it's possible you could get painted into a corner depending on which focused tools you picked to do some pieces of the process, and have to write your own glue or go on a long search).
jmiserez 9y ago
I work with self-hosted Gitlab daily and I’ve never thought the UI was bad or slow. In fact, I think it works pretty well. To the other commenters: Do you have any examples? Also, I’m excited about auto deployment. The less tools one needs to get software shipped, the better.
- foepys 9y ago
  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.
  - jamedjo 9y ago
    This comment reminded me to create issues for reducing clutter on the MR page [0], and expanding multiple resolved discussions [1] [0] https://gitlab.com/gitlab-org/gitlab-ce/issues/34814 https://gitlab.com/gitlab-org/gitlab-ce/issues/34814 [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/34813 https://gitlab.com/gitlab-org/gitlab-ce/issues/34813
  - cmatija 9y ago
    We're working on lots of UX improvements. There's a navigation overhaul planned [1], you can also check out a list of all current UX issues with [2]. As always, community feedback is something we always welcome wholeheartedly [3] [1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=UX https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... [3] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
cyphar 9y ago
> Gitlab's UI is bad-ish (this is what made me consider going to work there/contributing and helping fix that) If you'd asked me a year ago, I would've said some very harsh things at this point. But I just went to find examples of the issues I had a year ago (and we still have on our own internal GitLab instances), and it looks like most of them have been resolved. There's still weird duplication (why is there still a "Repository" tab when you can see the repo on the front page) but that's all just small warts that don't matter as much. I think GitLab still suffers from a weird workflow, but it's much better now than it was in the past. > Gitlab is slow. The reason why this is an issue is not the fault of the technology imo, but rather a fault of the marketing and community. GitLab is not meant to usurp https://github.com https://github.com. It's meant to be a viable alternative to GitHub EE. Unfortunately, there appears to be a split-brain in the community. GitLab themselves are saying that https://gitlab.com https://gitlab.com has scaling issues that they are working on resolving, but that self-hosting will not have these issues unless you're planning on running at the same scale as them. But the community appears to want more people to swap away from https://github.com https://github.com to https://gitlab.com https://gitlab.com (that's the impression I get). By doing that, you've now said "any comparisons between https://github.com https://github.com and https://gitlab.com https://gitlab.com are entirely valid because we're advertising them in the same capacity". That's selling yourselves short. If GitLab had decided to go for a federated model, then this sort of marketing problem wouldn't be nearly as much of an issue (you would run into the Mastodon effect, where everyone joins the "official server" -- but if you made it possible to migrate the users, permissions, issues and state of the repo then it wouldn't be a long-term concern). They didn't, and that's fine, but that means that marketing https://gitlab.com https://gitlab.com as a replacement for https://github.com https://github.com is going to just cause problems.

flipp3r 9y ago

"Gitlab dominates self-hosted git" Dont you mean, Gitlab, "2/3 of people surveyed by Bitrise, a CI service you may have never heard of, which is free, are using Gitlab, which is also free"

philtar 9y ago
The two statements are not mutually exclusive.
- madez 9y ago
  Neither implies the latter the former.
hardwaresofton 9y ago
I regret editorializing that fact from the article into the submission title. I should have just titled this submission "Gitlab's next step: Auto Deploy"

dehef 9y ago

I always use http://gitolite.com http://gitolite.com, thats enough. nb: I dont see the point of the graph about numbers of questions on SO. A high level of questions = A lot of problem, no :)?

usernam 9y ago
Couldn't agree more. Gitolite is enough for most use cases, and for technical users which often use other tools there's no need for a web interface (or anything beyond gitweb anyway). We use it in combination with BugsEverywhere for issue tracking, with the added advantage that bugs are tracked per-branch. You can work offline without issues. The major complaint with this system is the disconnect for users to report issues. BE includes a web frontend, but it's not great. We use mantis as a general tracker, but still keep detailed bug tracking in the VCS with BE.
raziel2p 9y ago
I really like gitolite, except how you need to add users and SSH keys through a git repository. I'd prefer just plain configuration files that I could manage with my configuration manager.
- lazarus101 9y ago
  I've wasted so many hours trying to convince Windows user that they don't need any passwords for gitolite, they just need to check that Pageant is running and has the right key loaded :D
cat199 9y ago
gitolite + redmine = sweetness.
lazarus101 9y ago
Yep, gitolite is awesome, it's so lightweight you can use pretty much any leftover PC to host repos for an entire company. I also use cgit for a fast and easy git web interface and ReviewBoard for code reviews. If I remember correctly gitlab initially started as a frontend for gitolite.

kondro 9y ago

Pretty sure both GitHub Enterprise and BitBucket Server are the dominant self-hosted Git solutions.

tlo 9y ago
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.
Sir_Substance 9y ago
Interesting statement. Gitlab provided a datasource. You've got a better one showing your counterpoint, I take it?
cyphar 9y ago
As mentioned in TFA, that was based on this source[1] which surveyed what "app developers" used. If you have alternative statistics, I'd be happy to see them, but GitLab did provide a source for their claim. [1]: http://blog.bitrise.io/2017/01/27/state-of-app-development-in-2016.html#self-hosted http://blog.bitrise.io/2017/01/27/state-of-app-development-i...
throwaway91111 9y ago
You're directly contradicting the article. Got any evidence?

bartvanH 9y ago

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.

cmatija 9y ago
GitLab is envisioned as a platform for the full SDLC - from idea to production [1][2]. If you don't want to use the CI, it shouldn't get in your way. We'd love to hear any specific suggestions you might have, since we're always looking to improve. You can open an issue about them in [3] if you want. [1] - https://about.gitlab.com/handbook/product/i2p-demo/ https://about.gitlab.com/handbook/product/i2p-demo/ [2] - https://about.gitlab.com/direction/#scope https://about.gitlab.com/direction/#scope [3] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
- mikepurvis 9y ago
  As GitLab user, I think the concern for me is split focus. For everywhere there's a tightly integrated built-in tool (issues, CI, container registry, etc), there also needs to be a separate, parallel effort to create, maintain, and document a sufficiently rich plugin interface that a third party can create a similarly tightly integrated experience when plugging in something external. Basically, they build the hooks but aren't dogfooding any of it, since their own integrations don't have to. And speaking from the perspective of someone using GitLab with Jira and Jenkins, it just isn't the same. Is that necessarily because of problems with the interface or is it just those specific plugins? I don't actually know.
  - brodock 9y ago
    GitLab CI started as a separate project, but team saw more benefits from integrating into a single product as it's much easier to provide tightly integration without the overhead of communication and APIs. There are places in the workflow that can't just support a hook for an external integration. While CI is integrated, it does not force you to use it, and there are ways to integrate with external solutions. While CI is part of the same product, you don't run the tests in the same machine, so you still need to provide the workers in additional ones or use the autoscalling mechanisms and have it bootstrap machines in the cloud as needed. So what I mean here is that while it is part of the product, it's mostly the "frontend" and the "APIs", the heavyload part of running it is totally optional.

deleted 9y ago

[deleted]

calafrax 9y ago

Gitlab is great. It took 5 minutes to install and has run flawlessly since. I was blown away by how complete, fully featured, and easy to use it is for a free product.

Snappy 9y ago
That's great to hear; thanks for the feedback!

willvarfar 9y ago

I would imagine that git dominates self-hosted git. I just have bare repos on servers I can ssh into. End of problem.

wonko1 9y ago
Of the 2 employers I've had who self-hosted, they both did this. I've also done this when self hosting, it's super easy. I guess there are probably no surveys of this though...
- corobo 9y ago
  It's super easy for you. I tried to set this up but it's such a pain in the backside to tell people how to pull the latest code. Ended up with Gitlab and haven't looked back. I didn't even realise Gitlab doesn't have auto-deploy yet.. We set up a .gitlab-ci.yml script that deploys the code.
  - deleted 9y ago
    [deleted]
pizza234 9y ago
Storage (/infrastructure) is only a small part of the GitHub/GitLab functionality; with a bare repos one solves only one problem of many :-)
deleted 9y ago
[deleted]
dmytrish 9y ago
For personal use, indeed, just use an ssh remote + gitweb interface with basic authentication and that's it. For organizations it makes sense to have something more featureful.
- u801e 9y ago
  For CI, you could have a git hook that could trigger a Jenkins build. For code review, you could use a tool like gerrit or phabricator or even set up an email list to send patch sets. What other features do Gitlab, Github, or Bitbucket have that wouldn't be covered by that type of setup?

anomie31 9y ago

Huh, I thought gogs and its forks dominated self hosted git, because it's just so easy to set up and use.

jpkeisala 9y ago

Does Gitlab have equivalent for Github Team account (5 users)?

cmatija 9y ago
We have free private repositories for all users and you can organize users into groups. Is this what you're looking for? If not, could you provide more context into what you're looking for?

knownothing 9y ago

"Gitlab dominates" 5% of the hosted market vs 95% of the SaaS market. And their reported popularity is based on data from a single CI company. This is further skewed since it's one of a few CI tools that actually supports Gitlab as an OAuth provider. There's no way this claim would stand up to any scrutiny or more data-gathering. It's just marketing fluff. EDIT: More on what upset me about this claim. First, we have no idea of what the composition of the 10,000 applications Bitrise surveyed are like. There could be a single company that uses Gitlab to test thousands of applications that completely invalidate this result. Second, this insults my (and every other competent readers') intelligence. This is badly done marketing. And their audience is developers. So they know they're misleading us but I guess they don't care.

zxcmx 9y ago
Stats don't make much sense. Self hosted bitbucket is huge. I've worked for Atlassian companies lately but none of their crap calls out to the Internet and tells the mothership what they're up to. Well I guess they do. But not in a way that other people can tell. Totally not an Atlassian shill (often I wish we had gitlab) but their stuff works self hosted real well. There's no way a third party could know what the numbers are, because when you use software which doesn't sell you out, well, you're not sold out.

wickchuck 9y ago

We've been on Gitlab since version 5 and for the most part it's been a pleasure to work with. The omnibus version has made things way easier to install/upgrade, so not sure what the fluff is about being hard to maintain. The UI is adequate and they are working on improvements to smooth out the rough edges a bit. Looking forward to the improvements and new features to come. Just wanted to post something positive instead of the nit picky hate I've been seeing lately about Gitlab...

jancsika 9y ago

For some reason, different parts of the Gitlab CI software expect different names for the runner binary-- possible names are gitlab-ci-multi-runner and gitlab-runner. If you set up a runner in a VM and want to upload artifacts, for some reason Gitlab CI requires you to install gitlab-ci-multi-runner on the VM guest (even though it is the host that is actually the runner). But when you do that, you have to actually go through the entire build process before seeing a non-terminal error that gitlab "couldn't find gitlab-runner". So now you have to go in on the VM guest, manually create a symlink from gitlab-ci-multi-runner to gitlab-runner, take a new snapshot of the VM state, and artifact upload will now work. I say "non-terminal" above because a failure to upload the artifact doesn't fail the build. So you can be looking at all checkmarks for everything in your pipeline and have no idea for which of those jobs you actually got artifacts. Also, every once in awhile I'll get failed builds where there is nothing at all in the build log. Typically, clicking "Retry" will successfully start a new build and complete successfully. Also, there is no way to specify to gitlab to keep only the last N artifacts. On the positive front, I finally figured out a way to set up an ssh server from within the msys2 environment in Windows, which requires no development whatsoever on the gitlab-ci infrastructure. That means gitlab-ci will ssh into msys2 on the runner, giving me a POSIX-y build environment on all my platforms. So that's nice. Sorry if this sounds overly negative and like a poor substitute for actually filing bugs. But the last time I worked on fixing a bug it took months for the maintainer just to click a button. This seems to be the only place I get timely response.

bikebilly 9y ago
Thanks for your feedback, we're seriously considering all the input from the community, wherever it is coming from. Talking about artifacts retention policy, we actually support defining an expiration date and we're also considering to add a maximum number in the future. You can find discussions about this topic in https://gitlab.com/gitlab-org/gitlab-ce/issues/23777 https://gitlab.com/gitlab-org/gitlab-ce/issues/23777 and https://gitlab.com/gitlab-org/gitlab-ce/issues/19208 https://gitlab.com/gitlab-org/gitlab-ce/issues/19208: in these issues there are also problems and consideration about having this feature implemented. Feel free to jump in and push your ideas!

Top19 9y ago

I really like Gitlab. It allows you to organize your repos, and do things like nesting them in categories. Why Github won't add this feature is beyond my understanding, and I really appreciate Gitlab stepping up and adding this into their platform. They also have a great system for migrating your repos over from Github.

claytonjy 9y ago
This! I'm at a small consulting shop (< 5 ppl), so it's really, really nice to have one subgroup per client; I'd hate having pages and pages of "client1-project1", "client1-project2", ... in a Github setup.

throwaway91111 9y ago

You know, this feature looks really cool, but the branding "Auto DevOps" seems like word-cloud clickbait and does not actually describe any distinguishing characteristics of the feature. DevOps is already a fuzzy area; what is Auto DevOps? It's at least another order of magnitude of semantic ambiguity.

alchemism 9y ago
The origin of "Auto DevOps" does seem to be a product branding creation: https://gitlab.com/gitlab-org/gitlab-ee/issues/2517 https://gitlab.com/gitlab-org/gitlab-ee/issues/2517
- throwaway91111 9y ago
  That issue should have basically been in the press release; it's a lot clearer when they dump the branding and focus on actual concrete features they provide.
  - Snappy 9y ago
    Thanks for the feedback. Maybe next time we talk about it, we'll be more clear about the features.

juiyout 9y ago

I can no longer imagine using a CI system without job scripts committed. Could someone let me know why jenkins is still more popular?