Group Organization Best Practices
Gitlab project best practice
Group/project structure
How to Organize Many Scripts in Gitlab (Groups vs Projects vs Repository Folders)
I finally got approval to start the process to migrate us away from the Atlassian Suite to self-hosted GitLab (Free EE to start, maybe Premium eventually) and want to make sure I'm putting us in a good spot moving forward. We're most likely sticking with Confluence longer term, and Jira in the intermediate while we initially focus on maturing our CI/CD. I'd like to get off of Jira sooner than later howerver.
I'm aware that GitLab can have many levels of groups and subgroups, but I'm having difficulty finding information on best practices on how to actually organize our projects besides some of the examples in the documentation.
Does anybody have some good examples of how to organize their projects? I'm looking at something like the following:
-
Development
-
Internal Tools
-
Products
-
Project A
-
Project B
-
-
-
Infrastructure
-
Cloud Provider Tools
-
IaC
-
Ansible
-
Terraform
-
-
System Configurations
-
-
Security
-
[Other departments as needed]
A few questions:
-
Even though we will be the only organization within this self-hosted instance, should we still create a root group for our organization? I'm of the understanding that this will allow issues across the organization to be viewed on a single board/list (I.E. for a Project Manager view) rather than them having to hit each top-level organization to see Development, Infrastructure, Security status
Organization Name
|____ Development
|____ Infrastructure
|____ Security -
I know that you can have up to 20 nestings of subgroups, but that seems like it would become a navigational nightmare. Is there a good balance between too deep or too shallow of groupings, or is this actually not an issue?
-
I read through all of the "Next Steps" documentation after installation, and am trying to absorb as much info as I can in the documentation or elsewhere. Anybody have any good resources or must have plugins/etc. for new installations that I might not have picked up via the docs?
Thanks!
Does anyone use groups in Gitlab as a placeholder to just place users into, as opposed to the traditional way of using groups as a project construct?
My thinking is to create a sub-group per team under our root group (which users are just guest via SSO), and add members into those groups as required. Then have another sub-folder under the root group for all projects, adding the relevant teams to the projects.
- Root
--Groups
---Group1
---Group2
--Projects
---Project1
---Project2
My current issue is that I've got a sub-project (say Project2) where I want to give ALL users read access to the repo (it's a CI template which I want them to be able to pull into their jobs). The only way at the moment seems to be by granting all users (via the default SSO role) at least the Reporter role, or I'm having to add each member to this project individually.
Side question - is it just me or is the whole permissions model in Gitlab a bit of kludge?
I am new to GitLab and am curious what the best practice is for Structure when it comes to many apps or in my case scripts.
Say I have hundreds of powershell scripts. Each script serves its own purpose, but could be semi-related to other scripts by topic.
For example:
-
Get-DNSRecords
-
Clear-PrintJobs
-
Clear-ADUserCustomAttribute
-
Get-ADGroupHierarcy
-
Get-ADGroupMembershipHistory
-
Get-ADExpiringPasswords
...
Notice some of these scripts are AD related and could be grouped/categorized as "AD Scripts". However, they aren't really related nor dependent on one another. Keep in mind this is just a small example, there would be HUNDREDS of scripts.
-
Would it be best practice to create a separate "Project" for each script? OR should/could multiple scripts be stored in separate folders within a single Project?
-
If a Single Project is used for multiple scripts, then you would need to cram instructions for each script into a single Readme.md, and there would be a lot of bloat within the repo, especially if you only really needed to work on a single script.
Is it normal to have many many hundreds of projects within a group? Each project would need to be separately cloned?
I hope someone can understand my confusion about this and provide any sort of guidance/recommendations.