api-first

2 posts

gitlab

GitLab Act 2 (opens in new tab)

GitLab is restructuring its organization and strategy to prepare for an agent-driven software industry. It expects AI agents to dramatically increase software production, making scalable infrastructure, orchestration, context, and governance more important than traditional developer tooling. The company is reducing geographic footprint and management layers while reorganizing R&D around smaller, autonomous teams, reaffirming its FY27 guidance pending final restructuring costs. ## Organizational Restructuring - GitLab is conducting the process openly, including a voluntary separation window. - The new organizational shape is expected to be finalized by June 1 where possible; local legal processes may extend timelines. - Planned operational changes include: - Reducing the number of countries with small GitLab teams by up to 30%, while relying on partners in affected markets. - Removing up to three management layers in some functions. - Reorganizing R&D into approximately 60 smaller teams with end-to-end ownership. - Automating internal reviews, approvals, and handoffs with AI agents, then adjusting roles accordingly. - The restructuring and strategic shift are related but independently justified. - GitLab will disclose the restructuring’s final scope and financial impact during its June 2 earnings call. ## Software Development in the Agentic Era - Software will increasingly be produced by machines under human direction. - Agents will plan, code, review, deploy, and repair software. - Engineers will remain responsible for architecture, customer understanding, judgment, and difficult tradeoffs. - Lower software-production costs are expected to expand demand for software and increase the value of developer platforms. - Deep engineering skills—such as system design, distributed systems, failure analysis, and integrating new capabilities safely—will become more important and scarce. - GitLab points to its Duo Agent Platform, released in January, as an initial investment in this future. ## Infrastructure for Machine-Scale Development - Agents can create merge requests, trigger pipelines, and push commits at volumes far beyond human teams. - Git and existing development platforms were not designed for this level of activity. - GitLab plans to: - Reengineer Git for machine-scale workloads. - Replace parts of its monolithic architecture with API-first, composable services. - Provide agent-specific APIs so agents can interact as first-class platform users. - The company argues that reliability, performance, and scalability at this level will become a major source of platform value. ## Orchestration Across the Software Lifecycle - Enterprises need more than individual agents that generate code or open merge requests; they need software that reaches production and delivers business value. - GitLab’s orchestration layer is intended to coordinate agents across the lifecycle by: - Assigning work and managing state. - Passing context between tasks. - Resolving conflicts. - Enforcing policies and guardrails. - Keeping humans involved where judgment is required. - CI/CD is being reconsidered as part of this shift, with orchestration serving as the runtime for validating and safely deploying machine-rate changes. ## Context as a Competitive Advantage - Code generation capabilities are increasingly similar across developer-tool vendors. - GitLab believes its advantage lies in the connected context accumulated across planning, code, review, security, deployment, and operations. - It plans to make this data model a first-class, API-accessible service. - More contextual information should allow agents to use fewer tokens and produce better results. ## Governance Built Into the Platform - As agents perform more work, enterprises need strong control over identity, permissions, policies, auditing, and data location. - GitLab intends to make governance core infrastructure rather than an add-on product. - Every agent, pipeline, and merge request should operate through platform services that can: - Control who or what may perform an action. - Record what happened and why. - Protect sensitive code and data. - Support flexible deployment models. ## One Platform, Three Modes - GitLab notes that most business software cannot realistically be rewritten for the agentic era. - Its platform strategy is therefore intended to support existing codebases alongside newer development models. - The provided text ends before explaining the three modes in detail. GitLab’s overall recommendation to itself is to reshape both its organization and platform around machine-scale software development, while preserving human control over architecture, judgment, and governance.

gitlab

GitLab metrics and registry features help reduce CI/CD bottlenecks (opens in new tab)

GitLab’s two new beta features target common CI/CD bottlenecks without requiring additional third-party tools. CI/CD Job Performance Metrics provides job-level visibility into duration and failures, while Container Virtual Registry centralizes pulls from multiple registries through a cached GitLab endpoint. Together, they help platform teams identify pipeline problems faster and simplify container management. ## CI/CD Job Performance Metrics - Available in GitLab Premium and Ultimate. - Limited beta on GitLab.com; available on Self-Managed and Dedicated with ClickHouse configured. - Adds a job-focused panel to **Analyze > CI/CD analytics**. - Shows, for the previous 30 days by default: - Median (P50) and worst-case (P95) job duration - Failure rate - Job name and pipeline stage - Supports sorting, searching, and pagination to identify slow or unreliable jobs. - GitLab plans to add stage-level aggregation for build, test, and deploy bottlenecks. ## Container Virtual Registry - Available in GitLab Premium and Ultimate; API-ready in GitLab 18.9. - Provides one GitLab endpoint for pulling images from multiple upstream registries. - Supports registries such as Docker Hub, Harbor, Quay, and other sources using long-lived token authentication. - Uses pull-through caching to: - Reduce repeated downloads and bandwidth costs - Improve availability and reliability - Centralize authentication and registry configuration - Currently configured through the API, with UI management in development. - Cloud registries requiring IAM authentication, including Amazon ECR, Google Artifact Registry, and Azure Container Registry, may be supported later. ## Beta Access and Feedback - GitLab.com users can request access through their customer success manager or the feature’s feedback issue. - Self-managed users can enable the feature flag and configure the virtual registry through the API. - GitLab is seeking feedback to guide future improvements to both features. These betas are worth evaluating if your team needs better visibility into pipeline performance or manages images across several registries. The metrics feature can replace custom dashboards, while the virtual registry can reduce registry-related configuration and operational overhead.