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.