Continuous Integration Pipelines Gain OpenTelemetry Tracing

A familiar term with new expectations

Continuous integration is one of the oldest ideas in modern software delivery. In 2026, though, the systems that run it are changing more than the definition is. The basic idea has not moved. Developers merge their changes into a shared repository often, and each merge starts an automated build and test run that checks whether the new code breaks anything already there.3132 Bitrise puts the cadence at several merges a day per developer. It describes the payoff as catching conflicts and bugs within minutes rather than days, which replaces the old "integration hell" of long-lived branches drifting away from main.34

What has changed is everything around that loop. CI pipelines are now treated as production systems. They are instrumented with the same telemetry used for live services, packaged by platform teams as self-service products, and held to security standards that once applied only to runtime infrastructure. The clearest evidence comes from four directions: the Kubernetes release cycle, the platform engineering movement, the spread of OpenTelemetry into build pipelines, and changes in the CI tools themselves.

The definition everyone agrees on

Vendor explanations of CI differ very little. Red Hat calls it the automated, frequent merging of code changes into a shared trunk. Each merge triggers unit and integration tests so the merged code can be trusted.31 Atlassian describes CI as a primary DevOps practice and names a version control system such as Git as the one thing it cannot work without.32 GitHub frames it as both a cultural habit of merging regularly and a technical process of automation and tooling, noting that containers are a popular way to create clean build environments.35

There is also broad agreement on how CI relates to the "CD" that follows it. Continuous delivery stops before automatically pushing to production. Continuous deployment releases every change that passes testing, with no manual gate.31 Bitrise argues that teams should adopt CI first and add delivery only once they trust their tests.34 Atlassian notes that CI is part of both delivery and deployment.40

The newer guidance goes further than the vendor primers. SRE-focused writing now treats CI as the first automated control point that protects service-level objectives and error budgets. It expects pipelines themselves to produce telemetry on success rates, flaky tests, and latency.37 That shift, from a developer convenience to something operations is accountable for, explains most of what follows.

Kubernetes releases put CI on a fixed schedule

For many teams, Kubernetes is where CI outputs end up, and its release cadence now sets the pace for pipeline maintenance. Kubernetes 1.34 reached end of life on October 27, 2026, after entering maintenance mode on August 27.35 After that date the project stops shipping patches for the branch, including fixes for newly disclosed vulnerabilities.10 Sources disagree slightly on when the final 1.34.12 patch landed. The upstream schedule targeted September 15, while endoflife.date lists September 23.54 The practical point is the same either way: that branch is closed.

The 1.35 release, nicknamed "Timbernetes," includes several changes that matter directly to pipeline authors. An optional kuberc file separates user preferences from cluster credentials so CI pipelines don't hit unexpected output changes.2 kubectl output now defaults to KYAML, a stricter YAML subset. The CNCF advises teams to review how it behaves before using it in CI templates and examples.7 A new terminatingReplicas field in Deployment status lets CI/CD tools see how many Pods are still shutting down. That gives a more honest answer to whether a rollout has actually finished.8

The release also brings changes that can break nodes. The kubelet won't start on nodes without cgroup v2. Release 1.35 is the last to support containerd 1.x, and kube-proxy's ipvs mode is deprecated.10 Netics points out that three branches stay supported at any time, with 1.35 closing on February 28, 2027. Its advice is that small platform teams should keep a register of which versions each cluster actually runs.3 Taken together, this means validating cluster upgrades has become ongoing CI work, not an occasional project.

The infrastructure layer is reworking its own CI as well. The K3s project moved its pull request and release pipelines from Drone to GitHub Actions. It cited greater transparency and the long-term continuity of its builds.6 RKE2's 1.35 release notes are full of CI fixes, including one for a "no such image" error in release CI.9 Even the people who build Kubernetes distributions spend real effort keeping their pipelines healthy.

Platform engineering turns pipelines into products

The biggest organizational change is that CI is increasingly something developers use rather than something they build. An AWS Builder Center piece argues that platform engineering is absorbing the "DevOps engineer" role. It describes a split between platform engineers who build the paved road and application engineers who simply use it. Anyone writing Jenkins pipelines or Argo CD setups today, it says, is already doing early platform work.26 Cloudmagazin describes the internal developer platform (IDP) as the new form of CI/CD. Its picture of an IDP bundles pipelines with infrastructure-as-code templates, OpenTelemetry-based observability, secrets management, policy-as-code, and a service catalog. Backstage serves as the common foundation.29

This is where the coverage most clearly disagrees. One widely shared post says platform engineering reached 80% enterprise adoption in 2026, with GitOps at 64%.21 That 80% figure matches a Gartner prediction from November 2023 that most software engineering organizations would have platform teams by 2026. However, Infragap reports that a SlashData survey for the CNCF found only 28% of developers saying their organization has a dedicated platform engineering team. Infragap also says it could not check that figure against the gated report.30 Other trend pieces cite precise gains attributed to named enterprises, such as 40% faster deployments, without links to primary data.23 These numbers are best treated as illustrations, not measurements.

On balance, the 80% figure looks like a forecast that is now being repeated as if it were a result. The real direction of travel is still clear. Organizations are standardizing CI templates, but fewer have dedicated platform teams than the most upbeat claims suggest. Cloudmagazin's warning fits this reading: the most common failure is running the IDP as an IT project instead of a product, which recreates a ticket-driven ops department under a new name.29

Observability reaches the build

The most concrete technical development is that CI pipelines can now be observed in a standard way. The OpenTelemetry project added CI/CD attributes to its semantic conventions in version 1.27.0. These cover pipelines, artifacts, version control, tests, and deployments. A dedicated CI/CD Observability SIG has been developing them since November 2023.11 One key attribute records the code revision, which lets a failed deployment be traced back to the commit that caused it. It also supplies data for DORA metrics such as change lead time.11

Tool vendors are adopting the conventions. In March 2026, CircleCI began exporting trace spans via OpenTelemetry for every finished pipeline, workflow, and job. It follows the semantic conventions where it can, adds its own attributes, and sends data to any OTLP-compatible backend.13 GitLab offers automatic export of pipeline telemetry, though the feature is still labeled an experiment.17 Jenkins has an official OpenTelemetry plugin that traces stages and steps without any changes to Jenkinsfiles.20 Dynatrace promotes tagging test spans to find flaky tests that slow releases.12 Red Hat shows how an OpenTelemetry collector can capture logs from short-lived OpenShift Pipelines pods before they vanish, keeping them for compliance audits.14

Coverage differs on how mature all this is. Dynatrace says the industry is "not there yet," and that teams still have to stitch several tools together.15 The project's own conventions for CI/CD are still at development status.16 That caution is justified. The standard exists and support from major tools is arriving, but end-to-end tracing from commit to production remains an integration job, not a default.

CI/CD tools and the security turn

The tool market looks stable on the surface. Jenkins is still dominant in large enterprises that have years invested in pipelines. GitHub Actions wins on convenience for teams already hosting code on GitHub.22 Underneath, the priorities are shifting toward security. One 2026 engineering reference argues that the pipeline itself is now a high-value target. Its main recommendation is to replace long-lived credentials with short-lived OIDC tokens, which GitHub Actions and GitLab CI both support.25 Other trend reports point the same way: policy-based pipelines, SBOMs, signed artifacts, and secret scanning are becoming baseline practice.24

AI claims are louder and harder to check. Some posts tout AI-driven test selection and automatic rollbacks with large percentage improvements.21 More measured coverage says AI can flag flaky tests and summarize failed builds, but that human oversight is still essential.28

The takeaway

Read together, the coverage suggests that "what is CI?" now has two answers. The textbook answer is frequent merges checked by automated builds and tests, and it has not changed. The working answer in 2026 is that CI is an observable, policy-enforcing system that is increasingly owned by a platform team. It runs on clusters that need a supported Kubernetes version every few months, and it will be judged by the same telemetry standards as production. Teams that still treat their pipeline as a black box are falling behind on all four fronts.