Originally reported by SD Times. This article summarises GitLab’s Complete DevOps announcement from October 2017.
The Problem GitLab Wanted to Solve
In the broader software industry circa 2017, development and operations teams typically relied on separate, specialised toolchains. Integrating those tools required custom glue code, ongoing maintenance, and constant context-switching — all of which slowed delivery and introduced coordination overhead. GitLab’s leadership argued that forcing teams to stitch together disparate tools created friction, degraded code quality, and undermined the core promise of DevOps: fast, reliable software delivery.
What GitLab Meant by “Complete DevOps”
GitLab defined Complete DevOps as a single, end-to-end platform that covers every phase of the software development lifecycle — from planning and coding through testing, deployment, monitoring, and operations — all within one user interface. The company articulated three core requirements for a Complete DevOps solution:
- A unified UI shared by both development and operations teams.
- Native integration across all DevOps phases, eliminating the need to manually connect third-party tools.
- Reduced friction between Dev and Ops, enabling genuine collaboration rather than hand-offs.
As GitLab put it at the time: “We want to close the loop between Dev and Ops, automating processes and reducing complexity so that you can focus on a great customer experience.”
Series C Funding to Back the Vision
To accelerate this roadmap, GitLab announced a $20 million Series C funding round. The company stated that the capital would be directed toward reimagining and restructuring its DevOps tooling to deliver the Complete DevOps experience — reducing friction, increasing cross-team collaboration, and giving organisations a competitive advantage through faster, higher-quality software delivery.
Key Pillars of the Complete DevOps Roadmap
GitLab’s Head of Product, Mark Pundsack, detailed the strategy in a blog post. The major capability areas announced were:
Dual Monitoring Dashboards
GitLab already provided a developer-centric monitoring dashboard. The roadmap called for a second, operations-focused dashboard showing an aggregated view of all projects in production. By giving both personas access to production status within the same tool, GitLab aimed to eliminate the need for separate observability platforms and keep Dev and Ops looking at a shared source of truth.
Automated Merge Requests
Rather than relying on manual notifications and manual code changes, GitLab planned to introduce the ability to automatically create and apply merge requests. The goal was to free developers from routine change management tasks and allow them to focus on feature work and problem-solving.
Cloud-Native Development
GitLab’s vision included a cloud-based development workflow that removes the need for developers to manage local language runtimes and dependency chains. Developers would make changes, push them to the platform, and commit to the repository — with the cloud handling environment consistency.
GitLab PaaS Built on Kubernetes
GitLab described a platform-as-a-service layer built on Kubernetes that would allow operations teams to manage their entire environment through GitLab’s own tooling — without developers ever needing to interact directly with the Kubernetes dashboard or CLI. This abstraction was central to reducing operational complexity for development teams.
Feature Flags
Feature flags let developers merge and deploy code without immediately exposing it to end users. This decouples deployment from release, enabling teams to:
- Merge smaller, more frequent changesets without user impact.
- Progressively roll out features to a controlled percentage of users.
- Roll back or disable a feature instantly if a defect is discovered, limiting blast radius.
Auto DevOps
Auto DevOps was positioned as a way to automatically detect a project’s programming language, build the application, and deploy it — reducing the pipeline configuration burden. GitLab noted that Kubernetes users could trigger Auto Build and Auto Deploy with a single click, lowering the barrier to a production-ready CI/CD pipeline.
Additional Roadmap Items
The broader DevOps strategy also referenced:
- Artifact management — centralised storage and versioning of build outputs.
- SLO tracking and auto-revert — automatically rolling back deployments that breach defined service-level objectives.
- Onboarding and adoption tooling — making it easier for new teams to adopt GitLab’s full feature set.
- Pipeline environment views — visualising the state of all environments directly within the pipeline interface.
The Underlying Philosophy
Central to GitLab’s Complete DevOps vision was a belief that all creative work should shift from read-only access to read-write participation — meaning every stakeholder, not just code authors, should be able to contribute meaningfully. By giving both developers and operators a shared platform with overlapping visibility into production, GitLab argued that organisations could break down the silos that traditionally slowed software delivery and compromised quality.
Why This Mattered in 2017 (and Still Does)
The announcement reflected a competitive positioning shift: GitLab was moving beyond source control and CI to directly challenge broader DevOps platform vendors. The Complete DevOps concept foreshadowed what would become a major industry trend — platform engineering and the consolidation of fragmented toolchains into unified internal developer platforms (IDPs). GitLab’s continued investment in features like Auto DevOps, Kubernetes integration, and feature flags has kept this vision central to its product strategy in the years since.