GitLab is a complete DevOps platform, delivered as a single application that does everything from project planning and source code management to CI/CD, monitoring, and security. The advantages of a single application are listed in the following paragraphs.
By delivering a single application we shorten cycle times, increase productivity, and thus create value for our customers.
Other vendors offer a kit plane you have to assemble yourself, GitLab is a type certified aircraft.
For example, the experience of one enterprise customer that converted from multiple DevOps tools to GitLab was:
You only have to login to one application. Users don't waste time logging in. You only have to set up one account. It is clear to users what account they should use. Due to less confusion phishing is harder.
GitLab does not require you to manage authorizations for each of its tools. This means that you set permissions once and everyone in your organization has the right access to every component.
Users don't have to set up or ask others to set up a project across applications. This can be a major source of delays.
With Auto DevOps your new projects have all the needed testing and deployment from the get go. And by having logging and security scanning happen automatically you reduce risk.
A single interface for all tools means that GitLab can always present the relevant context. Relatedly, any feature is always in its most optimal location. We don't have to force ourselves to create a new page to serve a new feature. The feature will just appear in the best designed existing location, simplifying navigation.
Also, you don't lose information due to constant context switching between different interfaces.
Users don't have to switch between applications constantly. Furthermore, if you're comfortable with one part of GitLab, you're comfortable with all of GitLab, as it all builds on the same interface components.
Running GitLab means that there is only one single application to install, maintain, scale, backup, network, and secure.
Updating GitLab means that everything is guaranteed to work as it did before. Maintaining separate components is often complicated by upgrades that change or break integration points, essentially breaking your software delivery pipeline. This will never happen with GitLab because everything is tested as an integrated whole.
GitLab uses a single data-store so you can get information about the whole software development lifecycle instead of parts of it. With multiple applications you not only have multiple databases but also different definitions, processes. Multiple data-stores lead to redundant and inconsistent data. You don't have to duplicate data nor do manual entry. There is a single source of truth without having to build a data warehouse.
Automated links between environments, code, issues, and epics provide a better overview of project state and progress. All information is realtime and there is a coherent set of concepts and definitions.
Using a single application means you don't have to integrate 10 different products. This saves time from your developers, reduces risk, increases reliability, and lowers the bill of external integrators. The flow is better for the more than 100,000 organizations and over 2,000 people using GitLab that use the same flow to contribute and make it great. If you have a developer tools department, they can now focus on other tasks to make your developers more effective.
You can deal with one vendor instead of multiple vendors pointing to each-other.
Your end user training becomes less complex; a multi-vendor environment means multiple trainers to manage.
We prefer to offer a single application instead of a network of services or offering plugins for the following reasons:
A single application across the entire DevOps lifecycle has unique, emergent benefits.
This is highlighted by analyst specified benefits of Value Stream Delivery Platforms, of which GitLab is considered a representative vendor.
Some additional example benefits include:
Pushing from CI to the container registry: before GitLab, this requires you to create a project and user account in a separate registry - and then on each job, credentials have to be passed between CI and the registry. With GitLab, none of this is necessary, because GitLab knows who you are and what your authorizations are in that project.
Because all decisions, code, changes and deploys happen in the same place and are linked to issues and merge requests, GitLab has a full audit log of every decision, change and deploy. So if anything goes wrong, discovering the source of the issues is simple and doesn't require checking multiple apps, teams and logs.
You deploy a change by merging a merge request. Because GitLab has monitoring built-in, it's able to show in the merge request that e.g. the error rate has increased. The responsible developer sees this with the correct context and can start to solve the issue immediately.
Enterprises that use a complex toolchain often need 20 people to manage all the interconnections while a single person can do the same work to administer GitLab. Here is a list of the various integrations necessary between tools:
Below is a flowchart illustration of the various integrations necessary between tools specified above.
When we have added aggregated logging we can move on to some security features that only a single application for the whole DevOps lifecycle can offer out of the box:
client_body_in_file_only and we don't need something like MITM proxy since we can use the SSL keys.Building and maintaining integration between multiple individual point tools comes with additional overt and hidden costs.
The overt cost of paying for licensing and support of multiple tools is higher than a single application. A single application can charge less because its fixed costs are distributed across the functionality, whereas separate vendors each need to pay those costs themselves for each of their solutions.
Businesses that manage a toolchain pay hidden operating costs in the form of engineering time needed to build and maintain the toolchain instead of using those engineering resources to write software with business logic that delivers differentiated value. For a large enterprise this can be the difference between paying 20 engineers vs one engineer to maintain your tools.
Conversational development carries a conversation across Departments and teams through the DevOps lifecycle, involving gatekeepers at every step. By providing relevant context, a feature that is only possible with an integrated solution like GitLab, we can reduce cycle time, making it easier to diagnose problems and make decisions.
Concretely, conversational development in GitLab means that a change can be easily followed from inception to the changes it made in performance and business metrics and feeding this information back to all stakeholders immediately.
Effectively, this allows cross-functional teams to collaborate effectively.
Review apps are the future of change review. They allow you to review not just the code, but the actual changes in a live environment. This means one no longer has to check out code locally to verify changes in a development environment, but you simply click on the environment link and try things out.
Only a tool that combines code review with CI/CD pipelines and integration with container schedulers (Kubernetes) is able to quickly create and shut down review apps and make them part of the review process.
Cycle analytics tell you how what your time to value, from planning to monitoring is. Only by having direct access to each step in the software development lifecycle, GitLab can give actionable data on time to value.
This means you can see where you are lagging and make meaningful change to ship faster.
Every GitLab projects comes with a container registry. That means there is no
need for elaborate configuration to be able to use and push container images in
CI. Rather, all you have to do is use a pre-defined
variable in
your CI configuration file (.gitlab-ci.yml).
Sometimes users ask if GitLab has particular module that contains a set of features. A modules-mindset results in narrowly-focused solutions and redundant features and abstractions. GitLab is a single application that solves entire use cases that might touch many parts of GitLab, without creating additional unnecessary complexity.
As GitLab breadth expands, but is maintained as a single application, new features are continually back-integrated into existing features. This means that existing features and the data that they have already generated over time accrue new value for very little cost in the context of the new features and their use cases.
Continuing apace after Microsoft's 2018 acquisition of GitHub, the trend to consolidate DevOps companies seems here to stay. In January 2019, Travis CI was acquired by Idera, and in February 2019 we saw Shippable acquired by JFrog. Atlassian and GitHub now both bundle CI/CD with SCM, alongside their ever-growing related suite of products. In January 2020, CollabNet acquired XebiaLabs to build out their version of a comprehensive DevOps solution.
It's natural for technology markets go through stages as they mature: when a young technology is first becoming popular, there is an explosion of tools to support it. New technologies have rough edges that make them difficult to use, and early tools tend to center around adoption of the new paradigm. Once the technology matures, consolidation is a natural part of the lifecycle. GitLab is in a fantastic position to be ahead of the curve on consolidation, as we're already considered a representative vendor in this newly defined market, but it's a position we need to actively defend as more competitors start to bring legitimately integrated products to market.