GitLab 19.0 adds secrets management and broader merge-request automation

GitLab shipped version 19.0 on May 21 with a public beta of GitLab Secrets Manager and a set of changes aimed at merge requests, pipeline standards, and regulated deployments. The official release overview presents the major version as connecting code creation with the controls needed to ship it.

Credentials and merge requests move closer to pipelines

Secrets Manager is intended to store CI/CD credentials within GitLab and inject them into jobs under project and group access controls. Public beta status warrants a staged evaluation: teams should verify rotation, audit logs, recovery, availability, and integrations before replacing an established secrets service.

GitLab also expanded Duo Developer across the merge-request lifecycle, including assistance with reviewer feedback and conflicts. A generated conflict resolution remains a code change. Reviewers need to confirm intent on both sides of the conflict and run tests that cover the combined behavior rather than accepting a clean merge as proof.

Platform teams get adoption signals

The release adds Components Analytics in the CI/CD Catalog. Usage counts are available broadly, while detailed project-and-version views depend on tier. This can help maintainers find consumers of shared pipeline components and plan upgrades, but an observed reference does not prove that a component ran successfully or remains supported.

Treat the major upgrade as both a product and dependency change. Read the breaking-change guide, test runners and integrations against a staging instance, and inventory deprecated behavior before scheduling production. For new AI or secrets features, document the deployment model and data path, especially in self-managed or isolated environments. GitLab 19.0 supplies more integrated controls; teams still need to define who can invoke them, how outputs are reviewed, and what rollback looks like.