Chef vs GitLab
Chef is a configuration management tool that enables deployment and maintentce of state for large scale infrasstructure. Chef excels as managing legacy infrastructure like physical servers and VMs. Chef was designed before widespread container adoption and does not implement Kubernetes natively.
GitLab is a single appliation for the whole DevOps lifecylce that includes not only configuration management, but also capabilities for proejct management, source code management, CI/CD, and monitoring. GitLab is designed for Kubernetes and cloud native applications.
GitLab can be used together with Chef to enable VM and bare metal configuration management. For Cloud Native applications run on Kubernetes, Chef is not required and GitLab can provide all the functionality natively.
AD / LDAP integration
Sync groups, manage SSH-keys, manage permissions, authentication and more. You can manage an entire GitLab instance through the LDAP / AD integration.
Granular user roles and flexible permissions
Manage access and permissions with five different user roles and settings for external users. Set permissions according to people’s role, rather than either read or write access to a repository. Don’t share the source code with people that only need access to the issue tracker.
GitLab and its CI/CD is Cloud Native, purpose built for the cloud model. GitLab can be easily deployed on Kubernetes and used to deploy your application to Kubernetes with support support out of the box.
Auto DevOps brings DevOps best practices to your project by automatically configuring software development lifecycles by default. It automatically detects, builds, tests, deploys, and monitors applications.
GitLab Enterprise Edition Premium ships with Deploy Boards offering a consolidated view of the current health and status of each CI environment running on Kubernetes. The status of each pod of your latest deployment is displayed seamlessly within GitLab without the need to access Kubernetes.
GitLab Enterprise Edition Premium can monitor your Canary Deployments when deploying your applications with Kubernetes.
Domain Specific Lanuage
A Domain Specific Lanuage (DSL) for defining infrstructure configuration allows thinking in resources, not files or commands to write declarative rather then procedural code.
Find, discover, and manage bare metal and VM servers. Provision using defined polices automatically installing the correct OS or hypervisors, based on the information discovered in your environment.
Model complex infrastructures and the dependencies between distributed services and systems that make up an application or application stack using infrastructure as code. The infrastructure orchestrator uses the model to manage deployment ensuring the right services are availabe, at the right time, with the right information.
Since GitLab fans wrote most of the text here there is a pro-GitLab bias. Nonetheless we try hard to ensure the comparisons are fair and factual. Please also add things that are great in other products but missing in GitLab. If you find something that is invalid, biased, missing, or out of date in the comparisons, please open a merge request for this website to correct it. As with all the pages on this website you can find where this page lives in the repository via the link in the footer.