One of the first problems that people see DevOps as a solution to is the creation of software release packages. The real problem that you’re fighting against is the common misconception between repeatability and reproducibility. Here’s my take.
Repeatability is a measure of the likelihood that, having produced one result from an experiment, you can try the same experiment, with the same setup, and produce that exact same result.
The reproducibility of data is a measure of whether results in a paper can be attained by a different research team, using the same methods. This shows that the results obtained are not artifacts of the unique setup in one research lab.
https://www.technologynetworks.com/informatics/articles/repeatability-vs-reproducibility-317157
Though these definitions are from another branch of science, they very much apply. A “works on my machine” developer likely has very repeatable results but not reproducible ones. This mindset isn’t conducive to the development process of your team because it’s a deflection of where the problem lies. If your code works on your machine and nowhere else it’s not someone else’s problem.
The simplest DevOps process should be one that forces reproducible results. If code lacks reproducibility (features not working correctly) it’s the process’ job to make sure that issue is taken care of. Your team must create code that has reproducible outputs and your DevOps solution must be repeatable, if it’s not then is it really helping you?
Orville Bailey 