GitLab 9.2 Released with Multiple Assignees for Issues and Pipeline Schedules | Hacker News Reader

GitLab 9.2 Released with Multiple Assignees for Issues and Pipeline Schedules

about.gitlab.com

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).

[1] https://news.ycombinator.com/item?id=14394123

Yes, I'm using and planing to use gitlab for all my current and future private projects instead of github. Keeping github for public stuff though

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

Just curious, if you're already using Trello - why not just use Atlassian since they bought Trello.

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.

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'm a Community Advocate at GitLab, what features are you missing from GitLab issues that prevented you from switching?

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.

+1 for the top level overview, although subgroups is a step in the right direction

* Issue visibility

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

“ 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.

Any reason why you're using Trello instead of GitLab Issue Boards? https://about.gitlab.com/features/issueboard/

Can you have public issue boards on private repositories (or private code repositories on public projects) with GitLab?

Trello is good for that sort of "feature request" behaviour.

Yes, you can set the access for each component of GitLab individually.

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.

>>"Self-hosted Gitlab+Mattermost has been a very good bet for us so far."

Any reason to use Mattermost now given that GitLab acquired Gitter (chat) [1]?

[1] https://venturebeat.com/2017/03/15/gitlab-acquires-software-...

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.

[1] https://about.gitlab.com/2017/05/22/gitlab-9-2-released/#omn...

We describe our plans for Gitter / Mattermost in this blog post: https://about.gitlab.com/2017/03/15/gitter-acquisition/

We intend to keep both around as they serve different purposes :)

Beware of cargo cults.

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.

What about TFS or Visual Studio Online through BizSpark?

https://bizspark.microsoft.com/

I love the TFS issues system.

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)

Thanks for the feedback.

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?

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.

Hiya,

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...

> while atlassian is not, they mostly care for their big customers

What do you base that comment on? Love to know how we can improve (beyond the things already listed above)

Scott (Atlassian CEO)

I don't think I've ever seen "ssh://" is ugly, "git://" is beautiful as an argument for/against a git server package before.

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.

Keep up the good work!

Thanks Mr Mondo!

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.

Thanks for the kind words. As mentioned in the release post we Internationalized Cycle Analytics. More translations are forthcoming.

I'm seriously considering switching to Gitlab. Multiple assignees makes sense for large projects.

GitHub's had multiple assignees since last year: https://github.com/blog/2178-multiple-assignees-on-issues-an...

I mean, switch if you want to switch. But I hope that that is not your main reason.

I've had other reasons to want to switch. It's still not enough to pull the trigger though.

What would make you switch?

For me getting something done for => https://gitlab.com/gitlab-org/gitlab-ee/issues/1020

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.

Thanks! I'll try to get an update on this. BTW code climate engine support in merge requests is coming in 9.3.

We are looking at the performance metrics over time now, based on the monitoring work we are doing.

What tools are you using to do your testing now?

Append to a sqlite database and have some adhoc queries on top of it.

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!

Very excited about official gitlab Helm charts! Awesome work.

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.

Hi orf,

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.

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:

minikube start --disk-size 80g --cpus 4 --memory 4080

Thanks orf, you are exactly right. The requirements exceed the minikube defaults, we will add this to the documentation as well.

This was done in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11624

Thanks for the quick turnaround! I'm not sure this is the issue though:

https://gitlab.com/gitlab-org/gitlab-ce/issues/32773

Reply on news.ycombinator.com