We have a mature operations team with existing pipelines that build container images for a third-party product running on Kubernetes. Our company recently acquired a development team that has strong experience writing Dockerfiles for its applications, but previously had little or no operations support.
Operations currently uses Azure DevOps, while development works in Bitbucket. We want to make use of the developers' Docker and application knowledge without creating confusing ownership boundaries.
One proposal is for operations to maintain and publish base images, with developers building their application images FROM those bases. However, it raises a concern: if a base image needs a security patch, would operations end up waiting for developers to rebuild every application?
Another idea is to keep the Dockerfiles in Azure DevOps and have the operations pipeline clone the source from Bitbucket before building everything. How do you divide ownership, repositories, and pipelines in a setup like this?
3 Answers
The cleanest split is usually for operations or the platform team to own the base images, registry, pipeline templates, scanning, and runtime policies. Developers should own the application Dockerfiles and everything needed to produce a working app image.
Publish supported base images on a schedule and whenever important vulnerabilities are fixed. Then trigger application rebuilds automatically when a new base-image tag is released. That way, patching does not depend on someone manually coordinating with every development team. The application source and Dockerfile can stay with the developers, while the shared build machinery remains centrally managed.
I would avoid moving developers’ Dockerfiles just to make the tools match. The important question is ownership, not which system stores the file. Keep the Dockerfile alongside the application code so it can be reviewed and tested with the app, then have a reusable operations pipeline build that source, apply the organization’s security checks, publish the image, and deploy it.
Operations can provide templates or shared pipeline components, while developers retain control of application-specific build steps. This gives both teams clear responsibilities without forcing one team to own every detail.
Try to make the dependency flow one-way: operations publishes supported base images, and application teams consume them. A new base-image release should start an automated rebuild and test of dependent applications. If a rebuild fails, the application team fixes the compatibility issue, but routine security patching should not require them to redesign the image.
Centralizing all Dockerfiles in the operations repository may appear simpler, but it often creates a bottleneck and makes application changes harder to review. Shared ownership boundaries and automated triggers tend to scale better than centralizing every build decision.
It also helps to use a distribution that backports security fixes instead of forcing a major version change for every vulnerability. Rebuilding against the patched base should usually be enough, while CI can catch the cases where an application really is incompatible.