Who should write Docker files?

Question

Once again company debate rages on who should write Docker files (including compose, interchangeable for this post).

The scenario is common in my work (developer and consultant) and I wanted to know if there is a hard and fast rule for the creation and management of Docker files. I have operated in the following three scenario:

1.) Dev-ops writes and manages the Docker files

Pros: they don't have surprises for production and ultimately control the final instance Cons: Devs are less informed on Docker/server, have to wait for certain changes or ask permission or need an ops team person to do something like add an environment variable

2.) Developers write and maintain Docker files

Pros: Devs keep on working, collisions and conflicts are resolved inside that team Cons: Dev-ops often is handed a bad or troubling Docker file for production. Dev ops also spends time fixing developer problems on the Docker file. Developers generally do not focus on security with respect to instance.

3.) Hybrid approach: Devs write the Docker file for their use in conjunction with dev-ops policy or needs. Dev-ops bases a different production docker file on the developers working Docker file but add in secret handling, Terraform/IaC/CI+CD needs, and takes responsibility for Docker files running on instance.

In this scenario dev-ops teams watched our (developer) files and used the differentials to ask questions or provide insight into changes.

--

The problem I run into over and over (regarding Docker files):

• Devs can't make simple changes for various reasons (scenario #1)
• Changes by devs upset dev-ops (all scenario)
• Dev-ops needs "2 weeks notice for any change" or similar unacceptable delay (scenario 1)
• Developers spend too much time learning how to be infrastructure compliant and lose productivity (scenario 1)
• Dev-ops get junk files (scenario2)
• liability for security and other ops related tasks are shared between departments (much infighting when things go wrong) (problematic in all scenario)

The list of experienced problems is quite long, but I hope this is enough information to establish a dialog on this topic from the professionals who handle Docker the most and take responsibility for uptime.

23July Responding to @MLu:

Dev ops is "Developer Operations", as in the deploy and infra side of things. "Working together" always happens, but these are two distinct career paths and domain of expertise (developer and operations). As the Wikipedia entry underscores my view, there is note regarding context dependence on the paradigm. Dev writes the code, Ops puts to instance, in the middle there is collaboration. So I don't agree at all that "DevOps model is exactly the blend of these two roles.", not in my 17 years on many teams.

One of the teams was considered "SRE" while another liked "Devops", and another "Infra (not even answering people who use devops)". Each team had their own ideas but the same problems in the end servicing the development aspect of projects.

Development and "Ops" as in CI/CD need to work together, but for some reason only these "ops" teams in all scenario were the acknowledged pain point. Why is this so common?

If DevOps is born of developer practices (agile, reliance on SCM, DRY, etc) and usually staffed by a high percentage of ex-developers why is the staffing diaspora in build/ship/pipeline generally slow to react or respond, require long lead time, and are generally the most common blocker on projects. I question the ivory castle declarations from these ops teams. When a team is overloaded, under performing, and diverges from established norms then the (the dogma of) "X needs to do the Y" could be a solution or grasping at straws?

I do agree with @MLu's commentary on management of Docker files via PR and other approaches outlined. I read the response as a hybrid approach that I prefer.

Frustration is rooted in a few projects where I was "Devops" and we had cloud based products with complicated CI/CD and other operations. Yet we never had devops problems. As soon as a dedicated team handles these elements things would slow down, uptime suffered, and the product release cycle was more stressful. A cadre of us are discussing alternatives to the current paradigms because we are repeating the same problem over and over, both in an org and across different jobs.

Answer 1

Isn't DevOps .. you know .. Devs and Ops working together, ideally in the same team?

What you refer to as Dev-ops in your post sounds very much like the traditional Operations - developers build something and hand it over to Operations for deployment. Well that's not DevOps.

DevOps model is exactly the blend of these two roles. Not necessarily in one person but ideally in one team. Some people in the team write the actual code and tests, some maintain CI/CD pipelines, some write packaging / build / Docker files, some look after deployment. All the above ideally driven by CI/CD so that most people in the team can focus on writing code. Building, packaging, testing, and deployment happens automatically.

In our team the Dockerfiles are in the same repo as the software sources we work on and any developer can update it if needed (through a PR of course). The deployment files (AWS CloudFormation, Terraform, etc) are in another repo and again anyone can update these through a PR. Once any change (source, Dockerfile, CloudFormation, ...) is committed and pushed to git it automatically builds and deploys to Dev environment.

Single click in the CI/CD interface can then promote it to Test and another click to Qual and then to Prod.

TL;DR What you describe is not DevOps but instead a traditional Dev and traditional Ops fighting each other ;)

Answer 2

I agree with MLu although my experience is generally in small teams where roles tend to get a bit blurred anyway. Taking the 'infrastructure as code' approach that led to dev ops, the dev ops team should be collaborating with the dev team just like the dev team collaborate internally to ensure features work together. Perhaps having separated teams is the problem and instead you should have project based teams that include all specialities working together. Again my experience is in small startup environments so this may be a big shift in a larger organisation used to departmentalisation.