Thanks for all your amazing hard work guys and gals, really truly appreciate all the effort that's been going into making GitLab releases faster, reliable and all the new features that have been coming out, especially around Issues and CI.
I upgraded our dev and then prod environments not after the announcement without a hitch.
If you're starting a company today, would you use Gitlab over it's competitors (Atlassian, GitHub)?
And keep in mind, I'm not talking about specifically using GitLab for "git". I mean, what technology stack would you use for:
- Issue tracking
- VCS
- Developer Chat
- CI/CD
- Project Boards / Project Management
I actually just asked this question today [1] but didn't get much of a response.
I know Atlassian is not properly but for a fully stack software development experience, it seems like my only true options are either GitLab or Atlassian (not GitHub).
I started recently, we're on git+gitlab(hosted), slack, Trello. We use Trello for all the tracking: support and bugs and features. I like the gitlab CI but we're not taking full advantage yet
Not OP, but we looked at a full Atlassian stack about a year ago. At the time anyway, it was very expensive for us and offered little benefit besides easy SSO. Plus we found that, in general, HipChat was inferior to Slack and Bitbucket inferior to GitLab. And the gap has increased steadily since then from what I have seen.
In the end, we're running with:
- Redmine for project management. JIRA is extremely painful to use as an agency with hundreds of active projects in our experience. GitLab issues are only now getting to a level where they could be useful for us
- GitLab for Git Repo hosting
- Jenkins for CI (and hopefully CD in the near future). This could be handled by GitLab now but we were all more comfortable at the time with Jenkins (when we decided on Jenkins, GitLab CI was still a thing)
- G Suite for email/calendar/docs/file sharing
- Slack for inter-office communication
- Zabbix for server monitoring
I'm currently re-evaluating our decisions and determining if these are the best options going forward. We're also considering writing our own project management/CRM/SEO software that actually fits our needs (we've yet to find a one-size-fits-all solution for all aspects of our business), but that is a huge investment that can't be taken lightly and I doubt will happen.
I think this may have been addressed in a recent release, but projects involve far more than just the development team; Design, project management, video/photography, client, SEO, etc. will all need to be using the system as well. Beyond that, a project starts long before development is even thought about. Most of those teams will be doing work, that needs to be tracked, well before we're ready to create a code repo. With the way things are (or were), code is front and center and half the team doesn't care about that at all. There are also projects that have no development at all from the other teams (video/photo shoots, SEO for customers we didn't build sites for, etc.)
You can only have one code base per repo, too. So our PM may go in and create a project for an app and then when we go to develop, realize we need two separate projects. Or maybe they will go create a new project for a new version of an existing site, but we will still be using the same codebase. It makes sense from their view point to track it separately and with a clean slate while from a code standpoint, it makes absolutely no sense.
Beyond that, I personally have 74 tickets assigned to me across a dozen or so projects. PMs are tracking tickets in dozens of projects simultaneously. The last time I looked, there was no good way of seeing an overview of everything like that.
Organizing by client while also ensuring that all users have access to all repos without allowing public access to the repo is also a pain.
If we were only a development company, we'd use it for sure. But GitLab is too tied to the code to be a complete project management tool. There's also the issue that we want to have our CRM in the same place (it currently isn't) and there is no way GitLab will ever offer that.
You can currently see an overview of issues and MRs assigned to you (as well as your GitLab TODOs).
* Repo access
You can narrow repo access to a certain group (i.e. make it internal) see [1]
* Group-level issue boards
We have an open issue for cross-project (group-level) issue boards, see [2]
* Multiple repos per project
We discussed opting for a non-repo-centric approach to projects in [3] Check out the discussion in there, to see our reasoning for sticking with one repo per project.
* Non code projects
You can disable the repository in a project, so you can focus on just the issues, or you can have a repository with only graphics.
We use both internally. Our organization project doesn't have a repository [4], and our marketing repo has lots of design stuff [5]
“ projects involve far more than just the development team; Design, project management, video/photography, client, SEO, etc. ”
This is an excellent point and something we are thinking a lot about. From a design point of you, we need a way to share and maintain multiple design files across a distributed team. This is something we are actively working to solve for ourselves within GitLab.
From a project management point of view, we need to be able to see all the issue the team is working on along with what is in the pipeline. Multiple assignees is just one step in our process to giving users a holistic view to the entire project.
Self-hosted Gitlab+Mattermost has been a very good bet for us so far.
JIRA was on the table too as it's more feature rich, but the costs were several times higher (especially when you start tacking on their CI tooling and stuff).
GitHub however was just too feature poor to be considered seriously - less features than GitLab and it's priced higher than JIRA.
Well, for one, it's still supported and actively included as part of this GitLab release [1].
I'm not sure their Gitter acquisition is intended to replace Mattermost. In fact, I wouldn't be surprised if it was integrated as an open, zero-overhead chat solution for a gitlab project, and then have it also presented in the mattermost client as a separate room for each project.
That would be a really nice integration so that as a Dev, I don't need another chat client or browser window running, but I'm also not requiring my users to install my chat client or sign in separately in order to communicate.
That said, I have no idea if their plans are similar to this or not.
I used both.
While Atlassian didn't included everything by default and misses lots of features (due to their plugin system which means that they don't necessary think they need to implement stuff) and Atlassian uses more resource and does not support git:// urls only the ugly ssh:// once.
If I think back I should've never switched from Jira+Stash+Jenkins, however we did the Switch to GitLab and somehow I'm not 100% happy. It's way way slower a lot of things in CE are just missing and the costs for our < 10 user company would be way higher with gitlab ee.
gitlab is easy to upgrade and the maintance feels a little bit more easy since jira/stash backup is way more complicated. however the jira is way better at managing issues (even the lightweight version of the boards is more simple and easier to use) and stash is extremly fast compared to anything on gitlab.
at the end everything has their tradeoffs, but I would prefer the Atlassian Stack since it never broke anything, while on GitLab we often run into issues (especially CI related)
Well to not write a wall of text, this were the most "disruptive" things:
- compared to JIRA Agile the issue board is a joke (it's hard to actually describe the differences, but basically we can't use the gitlab issue board since it either doesn't work correctly when closing issues via push or it just isn't as understandable as the jira versions)
- docker and the ci is a horrible experience (we had a jenkins build before, which always worked, however even the ssh way of gitlab ci sometimes fails randomly or can't be canceled or whatever)
Positive thinks about gitlab:
- your at least listening (while atlassian is not, they mostly care for their big customers)
however stability and performance should be your number one priority and not adding more stuff that might make that stuff worse. sometimes it's good to not add more stuff in some versions.
Automatic issue closing (e.g. via push or MR) should work (I just tried it out on a test repo) - see the docs[1]. Did you use the correct keyword? Maybe something went awry, but it's definitely supported. Or did I misunderstand you and closing them via push works, but the issue is something related to the issue board instead? Could you share a bit more info? We'd love to get that sorted out if it's a bug or problem.
* Issue Board usability
We'd like to make the issue board as best as it can be. Which part of it was confusing to you? Maybe we can open an issue about it and ping the UX team?
* CI
Could you detail the experiences you had with our CI? Were you using GitLab.com or a self-hosted instance? And if you were using GitLab.com, were you using your own or our shared runners?
You can definitely cancel jobs, strange that you had problems with it.
What failed in your job?
* Stability & Performance
With each release we're adding stability and performance improvements, see [2]. And as always, our infra team works hard to improve the same on GitLab.com, see [3]
Unfortunately somewhere along the way this was turned into an enterprise edition ticket. Would be nice to have this available for my personal install as well.
Features scheduled to be EE only are intended to be useful mainly for big organizations, you can find more information here: https://about.gitlab.com/about/#what-features-are-ee-only. The decision could be reverted, it depends also on feedback we receive from users, so feel free to discuss about that in the issue!
Hey Josh, I'm running it on Minikube though and the storage had provisioned without error. Perhaps I needed to allocate more disk space to my minikube instance (the default is only 20g), it would be good to include that in the documentation as well!
Minikube will be the gateway to most people trying this I assume. As such, you'd need to increase the default CPU/RAM/Disk for Minikube:
One of the things I like most about Gitlab, is the steady releases and improvements by small doses, making it easy to auto-upgrade and adapt as we go (with the occasional internal announcement: "hey, you can now do X in Gitlab, have fun"). I've used JIRA/Atlassian, Github and Redmine a lot, and by far, I like Gitlab the most.
My only point of friction, which is being worked on, but will presumably take some time: no internationalization of the user interface (UI translation). I manage two instances of Gitlab: one for our shop (where we communicate with clients), another for a large-ish free software project (with hundreds of people from all skills and all languages). We (obviously) try to take any step we can do to remove friction with tools, but language is an important factor that we often under-estimate.
45 comments
[ 3.0 ms ] story [ 94.3 ms ] threadI upgraded our dev and then prod environments not after the announcement without a hitch.
Keep up the good work!
And keep in mind, I'm not talking about specifically using GitLab for "git". I mean, what technology stack would you use for:
- Issue tracking
- VCS
- Developer Chat
- CI/CD
- Project Boards / Project Management
I actually just asked this question today [1] but didn't get much of a response.
I know Atlassian is not properly but for a fully stack software development experience, it seems like my only true options are either GitLab or Atlassian (not GitHub).
[1] https://news.ycombinator.com/item?id=14394123
Atlassian has HipChat (slack competitor), has Bitbucket (gitlab competitor), and has CI/CD.
You could make Atlassian a one-stop shop for all your software development needs.
Note: I do NOT work for any of the companies listed above. So I'm not secretly promoting my employer.
In the end, we're running with:
- Redmine for project management. JIRA is extremely painful to use as an agency with hundreds of active projects in our experience. GitLab issues are only now getting to a level where they could be useful for us - GitLab for Git Repo hosting - Jenkins for CI (and hopefully CD in the near future). This could be handled by GitLab now but we were all more comfortable at the time with Jenkins (when we decided on Jenkins, GitLab CI was still a thing) - G Suite for email/calendar/docs/file sharing - Slack for inter-office communication - Zabbix for server monitoring
I'm currently re-evaluating our decisions and determining if these are the best options going forward. We're also considering writing our own project management/CRM/SEO software that actually fits our needs (we've yet to find a one-size-fits-all solution for all aspects of our business), but that is a huge investment that can't be taken lightly and I doubt will happen.
You can only have one code base per repo, too. So our PM may go in and create a project for an app and then when we go to develop, realize we need two separate projects. Or maybe they will go create a new project for a new version of an existing site, but we will still be using the same codebase. It makes sense from their view point to track it separately and with a clean slate while from a code standpoint, it makes absolutely no sense.
Beyond that, I personally have 74 tickets assigned to me across a dozen or so projects. PMs are tracking tickets in dozens of projects simultaneously. The last time I looked, there was no good way of seeing an overview of everything like that.
Organizing by client while also ensuring that all users have access to all repos without allowing public access to the repo is also a pain.
If we were only a development company, we'd use it for sure. But GitLab is too tied to the code to be a complete project management tool. There's also the issue that we want to have our CRM in the same place (it currently isn't) and there is no way GitLab will ever offer that.
You can currently see an overview of issues and MRs assigned to you (as well as your GitLab TODOs).
* Repo access
You can narrow repo access to a certain group (i.e. make it internal) see [1]
* Group-level issue boards
We have an open issue for cross-project (group-level) issue boards, see [2]
* Multiple repos per project
We discussed opting for a non-repo-centric approach to projects in [3] Check out the discussion in there, to see our reasoning for sticking with one repo per project.
* Non code projects
You can disable the repository in a project, so you can focus on just the issues, or you can have a repository with only graphics.
We use both internally. Our organization project doesn't have a repository [4], and our marketing repo has lots of design stuff [5]
[1] - https://docs.gitlab.com/ee/user/permissions.html
[2] - https://gitlab.com/gitlab-org/gitlab-ee/issues/928
[3] - https://gitlab.com/gitlab-org/gitlab-ee/issues/1295
[4] - https://gitlab.com/gitlab-com/organization/issues
[5] - https://gitlab.com/gitlab-com/marketing/tree/master/design
This is an excellent point and something we are thinking a lot about. From a design point of you, we need a way to share and maintain multiple design files across a distributed team. This is something we are actively working to solve for ourselves within GitLab.
From a project management point of view, we need to be able to see all the issue the team is working on along with what is in the pipeline. Multiple assignees is just one step in our process to giving users a holistic view to the entire project.
Trello is good for that sort of "feature request" behaviour.
JIRA was on the table too as it's more feature rich, but the costs were several times higher (especially when you start tacking on their CI tooling and stuff).
GitHub however was just too feature poor to be considered seriously - less features than GitLab and it's priced higher than JIRA.
Any reason to use Mattermost now given that GitLab acquired Gitter (chat) [1]?
[1] https://venturebeat.com/2017/03/15/gitlab-acquires-software-...
I'm not sure their Gitter acquisition is intended to replace Mattermost. In fact, I wouldn't be surprised if it was integrated as an open, zero-overhead chat solution for a gitlab project, and then have it also presented in the mattermost client as a separate room for each project.
That would be a really nice integration so that as a Dev, I don't need another chat client or browser window running, but I'm also not requiring my users to install my chat client or sign in separately in order to communicate.
That said, I have no idea if their plans are similar to this or not.
[1] https://about.gitlab.com/2017/05/22/gitlab-9-2-released/#omn...
We intend to keep both around as they serve different purposes :)
Edit: Pointing out that you might not actually need to muck about with all this stuff when you're just starting out is not unreasonable.
https://bizspark.microsoft.com/
What do you need in GitLab to manage issues better?
Sorry to hear you ran into problems with your self hosted GitLab. What CI problem was the most disruptive?
Positive thinks about gitlab: - your at least listening (while atlassian is not, they mostly care for their big customers) however stability and performance should be your number one priority and not adding more stuff that might make that stuff worse. sometimes it's good to not add more stuff in some versions.
Thanks for sharing this feedback.
* Closing issues via push
Automatic issue closing (e.g. via push or MR) should work (I just tried it out on a test repo) - see the docs[1]. Did you use the correct keyword? Maybe something went awry, but it's definitely supported. Or did I misunderstand you and closing them via push works, but the issue is something related to the issue board instead? Could you share a bit more info? We'd love to get that sorted out if it's a bug or problem.
* Issue Board usability
We'd like to make the issue board as best as it can be. Which part of it was confusing to you? Maybe we can open an issue about it and ping the UX team?
* CI
Could you detail the experiences you had with our CI? Were you using GitLab.com or a self-hosted instance? And if you were using GitLab.com, were you using your own or our shared runners?
You can definitely cancel jobs, strange that you had problems with it.
What failed in your job?
* Stability & Performance
With each release we're adding stability and performance improvements, see [2]. And as always, our infra team works hard to improve the same on GitLab.com, see [3]
[1] - https://docs.gitlab.com/ee/user/project/issues/automatic_iss...
[2] - https://gitlab.com/gitlab-org/gitlab-ce/issues/?scope=all&ut...
[3] - https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...
What do you base that comment on? Love to know how we can improve (beyond the things already listed above)
Scott (Atlassian CEO)
I mean, switch if you want to switch. But I hope that that is not your main reason.
Patiently waiting for this since I reported this request to you in https://news.ycombinator.com/item?id=11092066 :)
Unfortunately somewhere along the way this was turned into an enterprise edition ticket. Would be nice to have this available for my personal install as well.
What tools are you using to do your testing now?
Just tried it out and was hit by the `gitlab` service not starting due to: "PersistentVolumeClaim is not bound, which was unexpected."
Shame, I'll try it in a few releases and see if it's improved.
Thanks for giving our Helm charts a try! That is actually a temporary error, because the pod is waiting on the underlying storage to provision.
If you wait a few minutes, the underlying PVC will finish provisioning and the pod will automatically retry starting. At that point it should succeed.
We will update our documentation to include this, sorry for the confusion.
Minikube will be the gateway to most people trying this I assume. As such, you'd need to increase the default CPU/RAM/Disk for Minikube:
minikube start --disk-size 80g --cpus 4 --memory 4080
https://gitlab.com/gitlab-org/gitlab-ce/issues/32773
My only point of friction, which is being worked on, but will presumably take some time: no internationalization of the user interface (UI translation). I manage two instances of Gitlab: one for our shop (where we communicate with clients), another for a large-ish free software project (with hundreds of people from all skills and all languages). We (obviously) try to take any step we can do to remove friction with tools, but language is an important factor that we often under-estimate.