How Lockheed Martin Reduced DevOps Maintenance by 90%

Git repositories, CI/CD, security scanning, issue tracking, container registries, compliance — in large engineering organizations, these tasks are often handled by different tools introduced at different times to address different needs.

This approach is not necessarily a problem in itself. Each solution may perform its function well. Complexity emerges later, when teams must maintain not only the software they build but also dozens of integrations, plugins, configurations, and separate environments.

At that point, the cost of the DevOps stack is no longer defined by licenses alone. Infrastructure, upgrades, integration maintenance and, often more importantly, engineering hours become part of the equation.

This was the situation Lockheed Martin faced —one of the world's largest aerospace and defense companies, with more than 10,000 software engineers. Its experience demonstrates what organizations can gain by moving from numerous separate toolchains toward a more standardized DevSecOps platform.

When the DevOps toolchain becomes a system of its own

Different Lockheed Martin organizations had historically used their own sets of DevOps tools, including ClearCase, Jenkins, Dimensions, Redmine, Bitbucket, and other solutions. Individual programs and product teams built their toolchains independently.

As a result, automation levels varied significantly across teams. Some had mature testing and continuous deployment processes, others relied on basic automation, while some operations remained manual.

This created several common challenges:

• each environment had to be maintained and upgraded separately;
• CI/CD and security practices differed across teams;
• reusing code and existing components was more difficult;
• pipeline changes had to be maintained across multiple environments;
• engineering resources were spent maintaining the toolchain rather than building the product.

For some teams, maintaining their own development environment took around 20 hours per week. In a 12-person team, this meant a significant portion of one engineer's capacity was continuously dedicated to keeping the environment running.

What changed with GitLab

Lockheed Martin began gradually standardizing its software development environment around GitLab.

Importantly, the goal was not to mechanically replace every existing tool. The company reduced the number of separate toolchains where maintaining them created unnecessary complexity, cost, and dependence on local configurations.

GitLab became a common platform for source code management, CI/CD, and a range of DevSecOps processes. This enabled Lockheed Martin to standardize pipelines while keeping enough flexibility for different project types.

In particular, Lockheed Martin created a catalog of reusable pipelines for popular programming languages, with ready-to-use modules for security scanning, container image builds, and versioning. The same pipeline configuration can be used across different environments, including isolated networks.

Today, the shared pipeline catalog handles up to 2,500 pipelines per minute.

The results in numbers

After consolidating a significant part of its DevOps processes on GitLab, Lockheed Martin achieved measurable results:

• up to 80x faster CI pipeline builds;
• thousands of Jenkins servers retired;
• maintenance time for individual development environments reduced by approximately 90%;
• self-service creation of a repository and complete CI pipeline reduced from at least 40 hours to approximately 30 minutes;
• approximately 64,000 projects running in GitLab.

The changes also affected delivery speed. Teams that previously released updates monthly or weekly were, in many cases, able to move to daily or multiple deliveries per day.

For legacy projects, the average frequency of moving changes into testing also increased significantly: from approximately once a month to roughly once every six days.

Why this is about more than faster CI/CD

An 80x improvement in pipeline build speed attracts attention, but for a CTO, the broader systemic impact matters more.

Engineering capacity previously spent maintaining Jenkins instances, local environments, and integrations could be redirected toward work directly related to software development.

According to Lockheed Martin, teams that had previously spent around 20 hours per week on maintenance required only a few hours after the transition. Across an organization with more than 10,000 software engineers, that translates into hundreds and thousands of engineering hours freed for higher-value work.

This is why evaluating a DevOps platform should go beyond license cost. Infrastructure, administration, upgrades, integration maintenance, and engineering time can represent a significant share of Total Cost of Ownership.

Standardization without sacrificing flexibility

For a large organization, consolidation cannot mean forcing every team into exactly the same process.

Lockheed Martin supports both teams that require rapid development cycles and mission-critical systems where changes must pass significantly stricter validation.

The company therefore built its approach around shared reusable pipeline templates that can be used across different environments and adapted to the requirements of individual projects.

This distinction matters: teams gain a common baseline process without losing the ability to adapt it when architecture, security, or business requirements demand it.

Security and compliance become part of the pipeline

Security is particularly important for Lockheed Martin, which works with defense and government systems where security and compliance requirements are integral to the software delivery process.

In a fragmented toolchain, security practices can vary across teams, while updates to individual components may require additional oversight.

Standardized GitLab pipelines made it possible to integrate security scanning and other checks directly into shared processes. As a result, teams gained a consistent baseline of automated security practices without configuring a separate set of tools each time.

GitLab + AWS: scaling CI/CD for thousands of developers

The rapid adoption of GitLab across Lockheed Martin created the next challenge: scaling the platform for a large number of users and pipeline runs.

To address this, Lockheed Martin, GitLab, and AWS worked together to optimize the CI/CD ecosystem. They deployed infrastructure using Infrastructure as Code, automated disaster recovery, and configured autoscaling to respond to demand.

The result: the build request queue stopped growing, dropping from 200 pending requests to zero, while code deployment time fell across the organization.

This stage demonstrates another advantage of the platform approach: once software delivery processes are standardized, they become significantly easier to scale and automate across the organization.

What this case means for CTOs

Lockheed Martin's experience does not mean that every organization should abandon Jenkins, GitHub, Jira, or any other existing tool.

A more useful question is: how much does maintaining the current DevOps stack actually cost, and how much of that complexity is truly necessary?

When assessing the current architecture, it is worth looking at three areas:

• Engineering time. How much time do DevOps and development teams spend maintaining pipelines, plugins, integrations, and environments?
• Duplication. How many different ways of performing the same operation exist across different teams?
• Dependencies. How much does build stability depend on manual configuration and the knowledge of individual people rather than on a single reproducible process?

If these costs grow along with the number of teams and projects, the problem may no longer lie with any individual tool, but with the architecture of the toolchain itself.

Does consolidation require a complete migration?

No. Lockheed Martin's experience demonstrates this as well.

The company did not eliminate every other toolchain. Some Jenkins instances and specialized environments remained where specific programs or customers required them.

However, their share became small enough that they no longer created systemic complexity across the organization.

A practical approach to GitLab therefore does not have to begin with the question, “How do we replace our entire stack?” Instead, organizations can identify the processes where consolidation can deliver the greatest impact: CI/CD, source code management, security, compliance, or standardization of development environments.

How Softprom can help

Moving toward a unified DevSecOps platform should start not with a list of GitLab features, but with an analysis of the current software delivery process.

The Softprom team helps organizations assess their existing DevOps toolchain, identify the highest operational costs, and decide which processes make sense to consolidate on GitLab and which are better left unchanged for now.

Softprom is an authorized GitLab partner across Central and Eastern Europe, the Caucasus, and Central Asia, supporting customers with solution assessment, licensing, migration planning, and developing DevSecOps practices.

Softprom prepared this material based on GitLab's publicly available customer story about Lockheed Martin. Read the original GitLab case study.