Probablemente desee obtener un servidor de desarrollo, y preferiblemente un entorno de preparación también. Nadie debería estar presionando desde lo local a la producción, excepto su propio sitio web personal. Su proceso de implementación solo debe ser compatible con dev-> staging-> prod. Probablemente desee a alguien responsable de firmar nuevos lanzamientos; dependiendo de la organización, esto puede ser un líder de proyecto, un control de calidad dedicado o un deber que rota cada semana (con un recordatorio tangible, por ejemplo, solo la persona con el juguete esponjoso esa semana llega a empujar). Sin embargo, discútalo primero con tu equipo para obtener la aceptación (ver más abajo).
Quiero que este comportamiento sea castigado de alguna manera o que sea lo más desagradable posible.
Podría hacer que su conjunto de pruebas (tiene uno de esos, ¿verdad?) Incluya una verificación que determine si está en un servidor de producción y, si lo hace, envía un correo electrónico a todos en la oficina Looks like $username is testing on prod, watch out. Quizás avergonzar públicamente a tu colega sería desagradable. O bien, podría crear restricciones técnicas, como prohibir la IP de su equipo de mirar productos (que puede levantar pero tiene que justificar).
Sin embargo, no lo recomiendo, se vería como el problema, no como la persona que está probando con productos y podría volverse muy impopular con las personas del equipo a las que no les importa.
¿Seguramente lo que realmente quieres no es que este comportamiento sea castigado sino que se detenga ?
Los forcé a nosotros / nosotros a usar [...]
Es fantástico que usted defienda las mejoras en el flujo de trabajo, pero parece que no piensa demasiado en sus colegas y / o que no cuenta con todo su apoyo. Es probable que esto provoque que los colegas interactúen a medias con el flujo de trabajo, haciendo lo mínimo necesario para que el código entre en producción y realmente no sigan el espíritu del flujo de trabajo, lo que significará más tiempo dedicado a la limpieza. Y cuando pasa más y más tiempo aclarando los resultados de una interacción inadecuada con el flujo de trabajo (porque a nadie más le importa, ¿verdad?) Todos los demás cuestionarán el flujo de trabajo en sí.
Así que comienza con una conversación.
Descubra por qué está sucediendo (¿la máquina de su colega no es tan buena para las pruebas? ¿Su colega no está seguro con las ramas de características o está atrapado en una mentalidad svn donde commit y push son lo mismo?), Explique por qué es un problema para usted que el código no probado en dev / staging / prod, y vea si puede hacer algo para cambiar por qué sucede (es más probable que su colega haga lo que quiera si acaba de hacer que sea mejor probarlo localmente que si lo acaba de reprender).
Si no puede resolverlo y realmente se reduce a una diferencia de opinión, programe una discusión en todo el equipo en su próxima reunión retrospectiva, vea lo que hacen y piensan sus colegas. Exponga su caso, pero escuche el consenso. Tal vez su equipo diga que está bien no probar las correcciones de texto localmente, y que solo tiene una regla que dice que no hay grandes características en el desarrollador sin probar. Escriba en la reunión y lea lo que decida colectivamente sobre lo que está permitido en cada uno de los entornos. Establezca una fecha en un par de meses para revisarla, tal vez en una retrospectiva.