What Is Build Automation Software?

Build automation software handles the process of compiling source code, running tests, packaging binaries, and deploying applications — automatically and repeatably. For DevOps and platform engineering teams, it is a foundational layer of any CI/CD pipeline. Rather than relying on manual steps that are error-prone and slow, build automation tools execute predefined workflows triggered by code commits, pull requests, or schedules.

The global market for these tools has grown steadily as organizations across industries accelerate software delivery cycles. Market research from around 2020 highlighted the sector as one with strong growth prospects through the mid-2020s, driven by cloud migration, DevOps adoption, and — unexpectedly — the shift to remote-first engineering during the COVID-19 pandemic.

Market Segments

By Deployment Type

• Cloud-based: Hosted and managed by a vendor. Teams access the service via browser or API without managing infrastructure. Examples include CircleCI, Travis CI, and Codeship. Lower operational overhead but may raise data residency concerns.
• Web-based / Self-hosted: Deployed on the organization’s own infrastructure or private cloud. Jenkins and TeamCity are typical choices here. Offers greater control over configuration, plugins, and security posture at the cost of operational burden.

By Organization Size

• Large Enterprises: Tend to require on-premises or hybrid deployments, advanced role-based access control, audit logging, and integration with enterprise toolchains (Active Directory, JIRA, Artifactory, etc.).
• SMEs (Small and Medium Enterprises): Often prefer SaaS-based tools with low setup friction and usage-based pricing. Speed to value matters more than deep customization.

Key Players in the Build Automation Market

The following tools are consistently cited as leading platforms in the build automation space. Each has a distinct positioning and set of trade-offs:

Note on Ansible and Chef: Both are primarily configuration management and infrastructure automation tools. They appear in build automation market reports because they are frequently integrated into CI/CD pipelines for deployment and environment provisioning steps, not because they replace a dedicated build server.

Regional Market Dynamics

Market research covering 2020 identified four primary regions driving build automation software adoption:

• North America: The largest market by revenue, driven by a high density of technology companies and mature DevOps practices.
• Europe: Strong adoption in financial services, automotive, and manufacturing sectors undergoing digital transformation.
• Asia-Pacific (APAC): The fastest-growing region, with significant investment in software development infrastructure across China, India, Japan, and South Korea.
• Rest of World (ROW): Emerging adoption, particularly in Latin America and the Middle East.

COVID-19’s Effect on Build Automation Adoption

The COVID-19 pandemic in 2020 had a measurable effect on DevOps tooling adoption. As organizations rapidly shifted to remote work, the need for reliable, automated pipelines became more acute — teams could no longer rely on informal, in-person coordination to manage build and release processes.

Key impacts observed across the industry included:

• Accelerated cloud migration: Remote teams favored SaaS-based CI/CD tools that required no on-premises infrastructure management.
• Increased pipeline reliability requirements: With distributed teams spanning time zones, fully automated builds and tests became essential rather than optional.
• Budget pressure on licensing: Some organizations shifted toward open-source tools (Jenkins, Gradle, Maven) to reduce costs during economic uncertainty.
• Growth for cloud-native vendors: CircleCI, GitHub Actions, and similar platforms saw increased sign-ups as teams modernized their toolchains rapidly.

Factors Driving Market Growth

• DevOps and Agile adoption: Organizations moving to shorter release cycles need automated build pipelines to keep pace.
• Microservices architecture: More services mean more independent build pipelines, increasing tool usage and licensing.
• Container and Kubernetes adoption: Containerized workloads require build tools that can produce and push container images as a first-class output.
• Regulatory requirements: Industries like finance and healthcare require reproducible, auditable builds — a natural fit for automation.

Market Restraints

• Complexity of migration: Switching from an established tool like Jenkins to a newer platform involves significant pipeline rewriting effort.
• Skills gap: Configuring and maintaining sophisticated build pipelines requires expertise that is not yet ubiquitous.
• Security concerns with SaaS tools: Enterprises with strict data governance policies may be reluctant to send build artifacts and source references through third-party cloud services.

Choosing the Right Build Automation Tool

There is no single best tool — the right choice depends on your stack, team size, and operational model. A practical decision framework:

1. Self-hosted vs. SaaS: If you need full control over build agents and network isolation, Jenkins or TeamCity on-premises is a safe starting point. If you want to minimize ops overhead, CircleCI or GitHub Actions is easier to start with.
2. Language and ecosystem: Maven and Gradle are specifically optimized for JVM projects. For polyglot environments, a general-purpose CI tool is more appropriate.
3. Existing toolchain: If you’re already on the Atlassian stack (Jira, Confluence, Bitbucket), Bamboo integrates tightly. Azure DevOps is the natural choice for Microsoft-centric shops.
4. Team size and budget: Jenkins is free but requires maintenance investment. Commercial tools like TeamCity offer support and polish but carry licensing costs at scale.

Summary

The global build automation software market encompasses a wide range of tools — from open-source build systems like Maven and Gradle to full CI/CD platforms like Jenkins, CircleCI, and Azure DevOps. Market research from 2020 pointed to strong projected growth, accelerated by cloud adoption and the operational demands of remote-first engineering during the pandemic. For DevOps teams, the strategic choice of build automation tooling has long-term implications for pipeline reliability, developer productivity, and total cost of ownership.

Original market summary source: Scientect (2020). Specific growth rate forecasts and revenue figures cited in the original report have not been independently verified and are not reproduced here.

Overview

JetBrains released TeamCity 2019.2.2, a maintenance update to its CI/CD platform that carries enough security weight for the vendor to strongly recommend that all customers upgrade as soon as possible. Alongside the security patches, the release delivers over 60 bug fixes, more than 20 performance improvements, and three new features.

Security Fixes

JetBrains has not publicly disclosed the technical details of the security vulnerabilities addressed in this release, which is a common responsible-disclosure practice to reduce the window of opportunity for exploitation before users can upgrade. The fact that the company issued an explicit “strongly recommend” upgrade advisory signals that the issues are rated significant rather than low-severity. Teams running any earlier 2019.x release should prioritize this update.

New Features

Three new capabilities were introduced in this release:

• Multiple Docker accounts in Docker Support: TeamCity’s Docker Support feature can now be configured with more than one Docker registry account, giving teams greater flexibility when working across multiple registries.
• Agent pool type distinction via REST API: The /app/rest/ui/agentPools endpoint now differentiates between regular agent pools and project agent pools, making it easier to build automation and integrations that act on pool type.
• Dynamic build problem investigation UI: The UI now refreshes automatically when a build problem investigation is updated, removing the need to manually reload the page to see the latest investigation status.

Usability Improvements

Several usability pain points were addressed:

• Compact build configuration presentation: The Clean-up settings page now shows a compact view for build configurations derived from multiple templates, reducing visual clutter.
• Name truncation fix: Names in the UI are no longer shortened unnecessarily when sufficient horizontal space is available.
• Build results auto-update: A bug that prevented build result information from refreshing automatically after a build completed has been resolved.

Bug Fixes: UI and Functional Issues

The release closes a broad set of UI and functional defects, including:

• No error message being displayed when branch retrieval for a drop-down control failed.
• The “Show all build problems” button on the build page rendering no results despite problems existing.

In total, more than 60 issues are addressed across the UI, VCS integrations, REST API, and build runner components.

Performance Fixes

More than 20 performance-related fixes are included. A notable regression introduced in 2019.2.1 caused TeamCity to run very slowly after upgrading; this is resolved in 2019.2.2. Teams that deferred upgrading to 2019.2.1 due to performance reports should find 2019.2.2 significantly more stable.

Database Layer Improvements

Several fixes target the database layer, which is critical in large TeamCity installations:

• LIMIT-style query support for Oracle and MS SQL: The DB layer has been extended to support row-limiting queries on Oracle and Microsoft SQL Server, improving compatibility and query efficiency on these backends.
• Connection pool exhaustion on high-core-count servers: A particularly impactful bug was fixed where servers with many CPU cores could stall with the error “Database connections pool exhausted” when disk I/O became slow due to a high number of threads writing load simultaneously. This is a significant stability fix for large, busy TeamCity installations.

Upgrade Recommendation

Given the combination of undisclosed security vulnerabilities and confirmed performance regressions fixed in this release, upgrading to TeamCity 2019.2.2 from any earlier 2019.x version is strongly advisable. Consult the official JetBrains TeamCity page and the TeamCity release notes for the full changelog before upgrading in production environments.

What Is Build Automation?

Build automation is the process of scripting and automating the steps required to turn source code into a deployable artifact. At a minimum this includes:

• Compiling source code into binary or bytecode
• Packaging binaries, assets, and dependencies into distributable formats (JARs, Docker images, npm packages, etc.)
• Running automated tests to validate correctness before deployment
• Publishing artifacts to registries or package repositories
• Triggering downstream pipelines for deployment or integration testing

When build automation is combined with version control hooks and automated deployment, the result is a Continuous Integration / Continuous Delivery (CI/CD) pipeline—the backbone of modern DevOps practice.

Key Build Automation Tools

The market includes tools that play different roles: some are build orchestrators (they define when builds run and coordinate pipeline steps), while others are build systems (they define how code is compiled and packaged). Many teams use tools from both categories together.

CI/CD Orchestrators

Build Systems and Package Managers

Configuration Management and Infrastructure Automation

• Ansible — Agentless automation using YAML playbooks; commonly used for provisioning build environments and deploying artifacts
• Chef — Ruby-based infrastructure-as-code; suited to teams managing large, heterogeneous server fleets

While Ansible and Chef are primarily infrastructure automation tools rather than build tools, they frequently appear in the broader CI/CD toolchain for environment setup and deployment stages.

Choosing the Right Build Automation Stack

No single tool fits every team. The following dimensions are worth evaluating before committing to a platform:

1. Hosting Model

SaaS tools (CircleCI, Travis CI, Codeship, Azure Pipelines cloud) eliminate infrastructure management overhead but require trusting a third party with your source code and build secrets. Self-hosted tools (Jenkins, TeamCity, Bamboo) give full control over data residency and network access but require your team to maintain the CI servers, storage, and scaling.

2. Ecosystem and Integrations

Jenkins has the largest plugin library, but that breadth comes with maintenance burden—plugins can become outdated or conflict. Purpose-built SaaS platforms often provide first-class integrations with popular registries, cloud providers, and notification services out of the box.

3. Pipeline-as-Code

All major modern tools support defining pipelines in version-controlled configuration files (Jenkinsfile, .circleci/config.yml, .travis.yml, azure-pipelines.yml). Prefer tools where pipeline configuration lives in the repository alongside application code—this enables code review, history, and reproducibility.

4. Build Speed and Caching

Build time directly affects developer feedback loops. Evaluate each tool’s support for dependency caching, parallelism, and incremental builds. Gradle’s build cache and CircleCI’s layer caching for Docker images are examples of features that meaningfully reduce build times on larger projects.

5. Cost at Scale

SaaS pricing is typically per concurrent build or per compute minute. Self-hosted tools have infrastructure costs instead. Model both against your expected build volume before choosing.

Global Adoption Patterns

Build automation adoption is global, with significant usage across North America, Europe, and the Asia-Pacific region. Key drivers include the widespread shift to agile and DevOps practices, growth in cloud-native application development, and increasing regulatory pressure to demonstrate repeatable, auditable software delivery processes. Organizations in financial services, healthcare, retail, and manufacturing verticals have all accelerated investment in CI/CD tooling over the past decade.

Open-source tools like Jenkins, Maven, and Gradle dominate in cost-sensitive or on-premises environments, while commercial SaaS platforms gain ground in organizations prioritizing developer experience and reduced operational overhead.

The Competitive Landscape Is Evolving

The build automation market has seen meaningful consolidation. CloudBees, built around Jenkins, has acquired several smaller CI vendors. GitHub Actions has entered the space with deep repository integration, increasing competitive pressure on standalone SaaS CI providers. GitLab CI/CD offers a tightly integrated alternative for teams already on the GitLab platform.

Teams evaluating tools today should also consider platform tools like GitHub Actions and GitLab CI, which were not widely available when earlier market reports in this space were published, but now represent major adoption share—particularly in greenfield projects.

Summary

Build automation software is a mature but actively evolving segment of the DevOps toolchain. Jenkins remains the most widely deployed self-hosted option due to its flexibility and plugin ecosystem. TeamCity and Bamboo serve teams that need commercial support and tighter integrations with JetBrains and Atlassian tooling respectively. CircleCI, Travis CI, and Codeship offer lower-friction SaaS alternatives. Gradle and Maven handle the lower-level build system concerns for JVM-based projects, while Ansible and Chef manage infrastructure automation at the edges of the pipeline.

The right choice depends on your team size, hosting preferences, existing toolchain, and budget. Evaluating at least two or three tools with a representative real-world pipeline before committing is always worthwhile.

What Is Build Automation Software?

Build automation software handles the process of compiling source code, running tests, packaging artefacts and triggering deployments — automatically and repeatably. Rather than relying on a developer to execute a sequence of manual steps, a build automation tool encodes that sequence as a pipeline or script that runs on every code change. This is the foundation of modern Continuous Integration and Continuous Delivery (CI/CD) practice.

Build automation tools vary widely in scope. Some focus purely on compiling and testing (Maven, Gradle), while others orchestrate entire delivery pipelines across multiple environments (Jenkins, TeamCity, CircleCI). Configuration management tools such as Ansible and Chef are often included in market surveys because they automate the environment provisioning that surrounds a build.

Key Tools in the Market

The following tools are widely referenced in enterprise CI/CD discussions. Each occupies a slightly different position in the build and delivery pipeline.

Jenkins

Jenkins is the most widely deployed open-source CI/CD server. Its plugin ecosystem (1,800+ plugins) allows it to integrate with almost any tool in the software delivery chain. Jenkins supports both declarative and scripted pipelines via Jenkinsfile, and it can be hosted on-premises or in a cloud VM. The trade-off is operational overhead: maintaining a Jenkins instance, its plugins and its agents requires dedicated effort.

TeamCity

JetBrains TeamCity is a commercial CI server with a generous free tier. It offers strong .NET and JVM ecosystem support, first-class build chain visualisation and deep integration with JetBrains IDEs. TeamCity is popular in organisations already using IntelliJ IDEA or the JetBrains toolchain.

CircleCI

CircleCI is a cloud-native CI/CD platform configured via a YAML file (.circleci/config.yml). It emphasises fast pipeline execution through parallelism, Docker layer caching and resource class selection. CircleCI also offers a self-hosted runner option for organisations with data-residency requirements.

Bamboo

Atlassian Bamboo is a CI/CD server that integrates natively with Jira and Bitbucket. It suits teams already invested in the Atlassian ecosystem. Bamboo supports both on-premises deployment and, more recently, cloud-based options through Atlassian’s hosted offerings.

Ansible

Ansible (Red Hat) is primarily an agentless configuration management and application deployment tool. It uses YAML playbooks to define infrastructure state and application deployment steps. While not a CI server itself, Ansible is commonly invoked as a deployment step within Jenkins, CircleCI or Azure Pipelines pipelines.

Azure Pipelines (formerly Team Foundation Server)

Microsoft’s Azure DevOps suite includes Azure Pipelines, which supports YAML-based pipelines, multi-stage deployments and integration with GitHub. Microsoft Team Foundation Server (TFS) was the on-premises predecessor; many enterprises are migrating TFS pipelines to Azure DevOps or GitHub Actions.

Apache Maven and Gradle

Maven and Gradle are build tools rather than CI servers. Maven uses an XML-based pom.xml to declare project structure and dependencies; Gradle uses a Groovy or Kotlin DSL for a more flexible, incremental build model. Both are typically invoked by a CI server (Jenkins, CircleCI, GitHub Actions) rather than replacing it.

Travis CI and Codeship

Travis CI was one of the first cloud CI services to achieve wide adoption for open-source projects via GitHub integration. Codeship (now part of CloudBees) offers both a simple hosted CI product and a more configurable pro tier. Both remain in active use, though competitive pressure from GitHub Actions and CircleCI has reshaped their market position.

Chef

Chef Infra is a Ruby-based configuration management platform that enforces desired infrastructure state using cookbooks and recipes. Like Ansible, it appears in build automation market surveys because it automates environment setup that underpins repeatable builds and deployments.

Deployment Models: Cloud-Based vs. Self-Hosted

Build automation tools are available in two broad deployment models, and most vendors now support both:

• Cloud-based (SaaS): The vendor manages the infrastructure. Build agents are provisioned on demand. Examples include CircleCI Cloud, Travis CI, Codeship and GitHub Actions. The main advantages are zero infrastructure management, elastic capacity and fast onboarding. The trade-offs are data egress costs, compliance constraints and less control over the build environment.
• Self-hosted / on-premises: The organisation runs the CI server on its own infrastructure or a private cloud tenant. Examples include Jenkins, TeamCity (on-premises licence), Bamboo Server and GitLab Runner on self-managed GitLab. This model suits regulated industries (financial services, healthcare, government) where source code and artefacts must not leave a private network.

Enterprise vs. SME Adoption Patterns

Build automation tooling is used across organisations of all sizes, but adoption patterns differ:

• Large enterprises typically favour tools with strong access control, audit logging, LDAP/SSO integration and support contracts. Jenkins (with the CloudBees distribution), TeamCity and Azure Pipelines are common choices. Enterprises also tend to run hybrid models — a self-hosted CI server triggering deployments to both on-premises and cloud environments.
• SMEs and startups generally prefer low-operational-overhead SaaS products. GitHub Actions, CircleCI and Travis CI are popular because they require no server maintenance and offer generous free tiers for public repositories. Cost predictability is a key concern as pipeline minutes scale with team size.

Competitive and Strategic Dynamics

Several macro-level forces are reshaping the build automation market:

Platform consolidation

GitHub Actions (launched 2018, GA 2019) dramatically changed competitive dynamics by embedding CI/CD directly into the world’s largest source code host. Teams that previously used a separate CI service can now define pipelines in the same repository without an additional account or integration. GitLab CI/CD performs the same consolidation within the GitLab platform.

Containerisation and ephemeral build environments

Docker and Kubernetes have become de facto infrastructure for build agents. Running each build job in a fresh container eliminates environment drift and improves reproducibility. All major CI platforms now support Docker-based build environments, and Kubernetes-native CI tools (Tekton, Argo Workflows) are gaining traction in cloud-native organisations.

Security and supply-chain concerns

High-profile software supply chain attacks have raised scrutiny of CI/CD pipelines as an attack surface. Features such as secret scanning, signed artefacts, SBOM generation and pipeline-as-code (so changes are code-reviewed) are increasingly table-stakes requirements rather than differentiators.

Developer experience

Teams are evaluating CI tools partly on the quality of the local development experience — how easy it is to run a pipeline locally before pushing to the remote server. Tools with good local runners (Act for GitHub Actions, the CircleCI CLI) reduce the feedback loop and developer frustration.

Choosing a Build Automation Tool: Key Evaluation Criteria

When evaluating build automation tools for your organisation, consider the following dimensions:

1. Pipeline-as-code support: Can pipeline definitions live in version control alongside application code?
2. Integration ecosystem: Does the tool integrate natively with your source control host, artefact registry, deployment targets and ticketing system?
3. Scalability model: How does the tool scale build agent capacity — static agents, cloud auto-scaling, or Kubernetes pods?
4. Security controls: Does it support role-based access, secrets management, audit logging and signed artefacts?
5. Operational overhead: Who is responsible for patching, upgrading and monitoring the CI infrastructure?
6. Cost model: Is pricing based on concurrent pipelines, build minutes, seats or a flat licence fee? How does cost scale with your projected usage?
7. Compliance requirements: Do data residency or regulatory constraints rule out SaaS options?

Summary

The build automation software market encompasses a broad set of tools — from build systems like Maven and Gradle, through CI servers like Jenkins, TeamCity and Bamboo, to cloud-native platforms like CircleCI and GitHub Actions, and infrastructure automation tools like Ansible and Chef. No single tool is universally correct. The right choice depends on your team’s size, existing toolchain, compliance posture and appetite for infrastructure management.

The clearest trend across the market is the shift toward pipeline-as-code, ephemeral container-based build environments and tighter integration between source control and CI/CD — driven by both developer productivity goals and software supply chain security requirements.

Overview

In July 2019, GitLab released the results of its third annual Global Developer Survey, the first edition to expand its scope beyond culture, workflow, and tooling to include operations and security groups. The goal was to produce a comprehensive picture of the entire software development lifecycle — not just the developer perspective. With responses from more than 4,000 software professionals, the survey surfaces both the measurable gains that come from mature DevOps adoption and the stubborn organisational friction that prevents many teams from reaching true DevSecOps.

“The big takeaway from this survey is that early adopters of strong DevOps models are experiencing greater security and finding it easier to innovate, but barriers still prevent developers and security teams from achieving true DevSecOps. Teams need a single solution that can provide visibility into both sides of the process for streamlined deployment.”

Sid Sijbrandij, CEO and Co-founder, GitLab

The Core Finding: Security and Development Teams Are Still Misaligned

Despite broad agreement that security must be embedded in the development lifecycle, the survey exposed deep, ongoing friction between security professionals and developers:

• 69% of developers say they are expected to write secure code.
• 49% of security professionals say they struggle to get developers to treat vulnerability remediation as a priority.
• 68% of security professionals believe fewer than half of developers can spot security vulnerabilities later in the lifecycle.
• Roughly half of security professionals reported that bugs are most often found by their team after code has already been merged in a test environment — too late to be cost-effective.

“Our research tells us that while most developers are aware of the dangers that vulnerabilities present and want to dramatically improve their security capabilities, they often still lack organisational support for prioritising secure code creation, increasing secure coding skills, and implementing automated scanning and testing tooling to make that happen sooner rather than later.”

Colin Fletcher, Manager, Market Research and Customer Insights, GitLab

The data points to a structural problem: responsibility for security is being pushed onto developers without providing them the training, tooling, or organisational backing to act on it effectively.

Mature vs. Immature DevOps Models: The Performance Gap

The survey drew a sharp distinction between organisations with mature DevOps implementations and those still in early stages. The difference is not cosmetic — it shows up directly in security outcomes, developer experience, and delivery speed.

Advantages of a Mature DevOps Model

• Security teams operating within a mature DevOps practice are 3× more likely to discover bugs before code is merged.
• They are 90% more likely to test between 91% and 100% of their codebase compared to organisations with early-stage DevOps.
• Developers in mature organisations are almost 1.5× more likely to feel innovative.
• They are 3× more likely to discover security vulnerabilities earlier in the pipeline.

Costs of a Poor DevOps Implementation

• Teams with immature DevOps are 2.5× more likely to encounter their greatest delays during the planning stage.
• They are 2.6× more likely to encounter bureaucratic red tape that slows their ability to quickly fix vulnerabilities.

Only about one-third of all respondents rated their organisation’s DevOps efforts as “good,” which suggests that the majority of organisations still have significant room to mature — and significant security risk as a result.

CI/CD Investment Is Growing

Continuous integration and delivery remain central to DevOps strategy, and investment appetite reflects that:

• 43% of respondents said their organisations practice continuous deployment — on-demand or multiple times per day.
• 41% deploy somewhere between once a day and once a month.
• Almost two-thirds of respondents said they planned to invest in infrastructure in 2019 specifically to support continuous integration, deployment, and delivery.

Taken together, the data suggests that CI/CD is no longer a differentiator but an expected operational baseline — the question for most organisations is how mature and automated that pipeline is, not whether it exists.

Remote Teams Outperform On-Site Teams on Security and Collaboration

One of the more counterintuitive findings from the 2019 survey is that distributed or mostly remote teams consistently outperformed their in-office counterparts on collaboration and security maturity metrics:

• Developers in mostly remote environments are 23% more likely to have good insight into what their colleagues are working on.
• Remote developers rate the maturity of their organisation’s security practices 29% higher than those working in a traditional office setting.
• Distributed teams are more likely to quantify and document their work than in-office teams.
• Operations professionals in remote teams are more than 2.5× more likely to be given sufficient notice to support developer work, compared to their on-site peers.

The likely explanation is structural: remote and distributed teams are forced to rely on written communication, shared documentation, and tooling to co-ordinate — habits that also happen to reinforce DevSecOps best practices like audit trails, documented runbooks, and transparent change management.

What the Data Means for DevSecOps Practitioners

The 2019 GitLab survey makes clear that DevSecOps is not primarily a tooling problem. The gap between developer and security teams is as much organisational and cultural as it is technical. Key action points that emerge from the data:

1. Shift security left in practice, not just policy. Expecting developers to write secure code without investing in training, automated scanning in the IDE, and pre-merge security gates creates responsibility without capability.
2. Measure DevOps maturity honestly. The one-third satisfaction rate suggests many teams overestimate their progress. Conduct internal audits against a recognised maturity model.
3. Automate vulnerability detection earlier in the pipeline. The 3× improvement in pre-merge bug detection seen in mature DevOps organisations is a direct result of automated SAST, DAST, and dependency scanning integrated into CI/CD — not manual review.
4. Invest in documentation and async communication norms. The remote-team findings suggest that written-first communication habits improve both collaboration and security, regardless of physical location.
5. Plan for CI/CD infrastructure as a security control. Continuous deployment without comprehensive automated testing is a risk amplifier. The infrastructure investment appetite reported in the survey should be directed toward security testing coverage alongside deployment velocity.

Survey Methodology

GitLab surveyed 4,071 software professionals between 23 January and 27 February 2019. The reported margin of error is ±2%, calculated assuming a population of 23 million software professionals at a 95% confidence level. Respondents included developers, security professionals, and operations practitioners across a range of organisation sizes and industries.

The full 2019 Global Developer Report: DevSecOps was published on the GitLab website. Readers interested in the primary source data should search for it directly on about.gitlab.com.