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