Determine the various training areas for GitLab onboarding
To ensure our onboarding covers as much of what we deem needed as possible, we need to determine what areas training would be needed on.
Current list:
- Setup
- Installing GitLab via Source
- Installing GitLab via Omnibus
- Installing GitLab via Docker
- Installing GitLab via Helm
- Rails console overview
- GitLab Tools
- ZenDesk and Salesforce
- License Tool
- dev-resources
- Manage
- UI
- Admin panel
- Adjusting settings
- User management
- Group management
- 2FA
- User creation
- SSH keys
- Tokens
- Changing passwords
- Audit logs
- Authentication
- Admin panel
- Omniauth/SSO
- LDAP
- SAML
- CLI
- Reviewing log files
- User management
- Changing user passwords
- Disabling 2FA
- UI
- Plan
- UI
- Issues and Issue Boards
- Epics
- Milestones
- Roadmaps
- Projects
- Service Desk
- Markdown
- JIRA integration
- JIRA DVCS integration
- UI
- Create
- UI
- WebIDE
- Source code management
- Mirroring
- ElasticSearch integration
- Gitaly
- gitlab-shell
- gitlab-workhorse
- git-lfs
- UI
- Verify
- CI
- Code Quality
- Performance testing
- Runners
- Shell executor
- Docker executor
- Kubernetes executor
- Autoscaling runners
- Artifacts
- Creation
- Deletion
- Management
- CI
- Package
- Docker Registry
- Maven Registry
- NPM Registry
- Release
- CD
- GitLab Pages
- Feature Flags
- Configure
- AutoDevOps
- Kubernetes integration
- ChatOps
- Monitor
- Metrics
- Prometheus
- Grafana
- Kubernetes pod logging
- Performance Optimization/Troubleshooting
- Sidekiq Cluster
- Unicorn tuning
- Secure
- CI/CD
- SAST
- DAST
- Dependency Scanning
- Security Reports
- CI/CD
- Defend
- Coming 2019
- Growth
- Scaling
- Vertically
- Horizontally (HA)
- Scaling
- Enablement
- Omnnibus
- Cloud Native
- Licensing
- Geo
- Other integrations
- GitLab API
I like the idea of sticking to the DevOps Stages in the module planning. I am seeing some areas that should probably be hit prior to that, such as installing GitLab via source and Omnibus.
Edited by Jason Colyer