Necesita un proceso de control de calidad (QA) adecuado.

En un equipo de desarrollo de software profesional, no se impulsa desde el desarrollo hasta la producción. Tiene al menos tres entornos separados: desarrollo, organización y producción.

Cuando piensa que tiene algo funcionando en su entorno de desarrollo, primero empuja a la puesta en escena, donde el equipo de control de calidad prueba cada compromiso, y solo si esa prueba es exitosa, pasa a producción. Idealmente, el desarrollo, las pruebas y el empuje a la producción son realizados por personas separadas. Esto se puede garantizar configurando su sistema de automatización de compilación de manera que los desarrolladores solo puedan implementar desde el desarrollo hasta la puesta en escena y que el equipo de control de calidad solo pueda implementarlo desde la puesta en escena hasta la producción.

Cuando no puede persuadir a la gerencia para que contrate a alguien para que realice su control de calidad, tal vez uno de ustedes pueda desempeñar ese papel para el otro. Nunca trabajé con diploy.io, pero algunos sistemas de automatización de compilación se pueden configurar de manera que un usuario pueda implementar tanto desde el desarrollo hasta la puesta en escena como desde la puesta en escena a la producción, pero no hacer ambas cosas para la misma compilación, por lo que siempre hay una segunda persona requerido (pero asegúrate de tener algunas personas de respaldo para los momentos en que uno de ustedes esté ausente).

Otra opción es que su personal de soporte realice el control de calidad. Esto puede parecer un trabajo adicional para ellos, pero también se asegura de que estén al tanto de cualquier cambio en la aplicación que pueda asegurarles algún trabajo a largo plazo.

Probablemente querrá obtener un servidor de desarrollo y, preferiblemente, también un entorno de prueba. Nadie debería empujar de lo local a la producción, excepto su propio sitio web personal. Su proceso de implementación solo debe admitir dev- > staging- > prod. Probablemente quiera a alguien responsable de aprobar los 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 mullido que la semana obtiene). empujar). Sin embargo, coméntelo con su equipo primero 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 suite de prueba (tenga uno de esos, ¿verdad?) incluya un cheque que determine si está en un servidor de producción y, si lo hace, le envía a todos en la oficina un correo electrónico que dice Looks like $username is testing on prod, watch out . Tal vez avergonzar públicamente a tu colega sería desagradable. O podría crear restricciones técnicas, como prohibir la IP de su equipo de mirar prod (que puede levantar pero que debe justificar).

No lo recomiendo, sin embargo, te verías como el problema, no como la persona que realiza las pruebas y podrías hacerte muy impopular con las personas del equipo que no se preocupan.

Seguramente lo que realmente quieres no es que este comportamiento sea castigado, sino que se detenga .

  

Los forcé / usamos para usar [...]

Es fantástico que esté promoviendo mejoras en el flujo de trabajo, pero parece que no cree mucho en sus colegas y / o que no tiene todo su apoyo. Es probable que esto resulte en 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 no sigan realmente 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 limpiando 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í mismo.

Así que empieza con una conversación.

Averigüe por qué está sucediendo (¿la máquina de su colega no es tan buena para las pruebas? ¿Su colega no está seguro con las características principales o está atascado en una mentalidad de svn donde cometer y empujar son lo mismo?), explique por qué es un problema para usted que el código no probado sigue 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 las pruebas localmente mejor que si acaba de regañar ellos).

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. Haz tu caso, pero escucha el consenso. Tal vez su equipo diga que está bien no probar las correcciones textuales de forma local, y simplemente tiene una regla que indica que no se han probado grandes características en el desarrollo. Escriba en la reunión y lea lo que decide colectivamente sobre lo que se permite en cada uno de los entornos. Establezca una fecha en un par de meses para revisarlo, tal vez en una retrospectiva.

En el trabajo, evitamos esto utilizando Gerrit . Gerrit es un sistema de revisión de código que actúa como una puerta para su sucursal principal / de producción Git que se denomina convencionalmente "maestro". Usted tiene revisiones de código, ¿verdad? Parece que personalmente los haces excepcionalmente. Con Gerrit, usted empuja a una especie de rama de ensayo que, después de que usted y su compañero de trabajo hayan ejecutado satisfactoriamente el proceso de revisión de código, Gerrit se fusiona con su rama principal. Incluso puede conectar Gerrit a un servidor CI para ejecutar pruebas unitarias antes de que alguien reciba un correo electrónico para revisar un cambio. Si no tiene un servidor, puede configurar una herramienta de CI, Codeship tiene un buen plan gratuito para usar como prueba de concepto.

Por último, por supuesto, es automatizar las implementaciones de producción solo a partir de productos de compilación autorizados que han sobrevivido a la revisión del código y las pruebas unitarias. Hay algunas tecnologías geniales para esto, que no mencionaré por temor a ser un cebo de fuego.

Ve a tu jefe con una solución. Este se aplica incluso a usted, y es una forma de mejorar la calidad del código de todos, no solo de castigar a su compañero de trabajo.

Veo esto como un problema en gran parte humano: el proceso está ahí y las herramientas están ahí, pero el proceso simplemente no se está siguiendo.

Estoy de acuerdo con lo que otros han dicho aquí, sobre la posibilidad de que es muy posible que el desarrollador en cuestión se quede atascado en un SVN mentalidad, y bien podría pensar que está siguiendo el proceso.

Encuentro que la mejor manera de abordar este tipo de problema, especialmente cuando no hay un superior claro, no gira en torno al castigo o la eliminación del acceso; esto solo conduce al resentimiento y como suena como si fueras el fuerte partidario de seguir el proceso (siempre hay uno, y yo he sido 'ese tipo' antes), es usted quien probablemente se enoje más. Se trata de lograr que las personas lleguen a un acuerdo sobre el proceso primero.

Aquí es donde las reuniones estructuradas, como las reuniones de tipo "lecciones aprendidas" después de un incidente importante en la producción, pueden ser muy útiles. Trate de que todos estén de acuerdo, incluido el desarrollador en cuestión, que la revisión del código, las pruebas unitarias, las pruebas integrales, etc. deben realizarse todas las veces (y también puede comenzar a presentar la idea de un entorno de prueba aquí). No debería ser difícil, y es muy sensible. Luego, pídale al equipo que formule algunas reglas sólidas sobre cómo debe hacerse. Cuanto más contribuya el desarrollador que está causando el problema, más sentirán que se adhieren a las reglas y comienzan a ver por qué su comportamiento ha sido un problema.

El punto final, es nunca caer en el "bueno, ¡es mejor de lo que solía ser!" trampa. Siempre hay espacio para mejorar. Es común que las personas en la industria de TI, en mi experiencia, comiencen a conformarse con lo que tienen, después de algunas mejoras. El asentamiento continúa luego, hasta que de repente te encuentras en un punto de crisis nuevamente.

Esto no es raro , particularmente en equipos pequeños . No hagas una gran cosa al respecto, pero haz una regla informal:

Rompe la construcción, trae donas.

O bien 1) Obtendrá donas dos veces por semana o 2) se adherirán a la norma.

Tráigalo en una reunión. Sin acusar a nadie, no mencione a nadie por su nombre, sino algo similar a, "Desde que introdujimos los estándares de implementación y control de versiones, las cosas se han vuelto mucho más fáciles y el servidor está más tiempo del que solía estar. Esto Sin embargo, sigue siendo tentador tomar un atajo y enviarlo sin las pruebas adecuadas. Sin embargo, es una apuesta, y nuestro servidor está en línea. Sugiero que de ahora en adelante si alguno de nosotros envía un código que rompe el servidor, la persona responsable trae donuts para el equipo al día siguiente ".

Si lo desea, sustituya otra cosa por donas, y no la haga cara: el almuerzo para todo el equipo sería demasiado, pero una caja de $ 5 de donas o una bandeja de frutas / verduras, o papas fritas y salsa, etc. Probablemente sea lo suficientemente molesto para hacer que realmente sopesen el riesgo con la conveniencia de saltarse las pruebas sin que sea una carga que los aleje del equipo o la compañía.

  

Ahora, ¿cómo puedo forzarlos ...

En lugar de forzar a tus colegas, intenta hacer que vean las cosas desde tu perspectiva. Esto hará las cosas mucho más fáciles para todos. Lo que me lleva a ...

  

Quiero que este comportamiento sea castigado de alguna manera o que sea desagradable   tanto como sea posible.

¿Por qué es un dolor para ti tener problemas en el servidor en vivo, pero no para este tipo? ¿Sabes algo que él no sabe? ¿Qué puedes hacer para que vea las cosas como tú?

Si tienes éxito con esto, sacarás lo mejor de él y él encontrará soluciones al problema que nunca pensaste.

En general, intente trabajar junto con las personas para resolver problemas en lugar de forzarlos a procesos que no comprenden.

¿Qué es lo peor que podría pasar? ¿Tiene copias de seguridad que sean lo suficientemente buenas como para que un error que modifica registros aleatorios en su base de datos pueda solucionarse restaurando una versión anterior?

Supongamos que tiene un error en el uso de un ID de registro y, por error, la cantidad de una factura en centavos se almacena en una variable utilizada para el ID de registro. Entonces, si pago $ 12.34, entonces se modificará el registro con id 1234. ¿Puede recuperarse de eso, si el software se ejecuta durante algunas horas hasta que se detecta el error? (Si se actualizan tanto el registro correcto como el registro 1234, solo lo detectaría cuando se use el registro 1234, por lo que esto podría pasar desapercibido durante bastante tiempo).

Ahora pregunte a su desarrollador altamente motivado qué piensa acerca de esto. Obviamente, no puede afirmar que nunca comete errores, porque lo ha hecho en el pasado.

Usted entiende claramente varios procesos posibles y soluciones técnicas. El problema es cómo gestionar el compañero de trabajo.

Esto es esencialmente un ejercicio de gestión del cambio.

En primer lugar, me gustaría hablar con el fundador para asegurarme de que él / ella esté a bordo con su punto de vista. Si hay una interrupción en la producción, esperaría que el fundador estuviera muy preocupado por eso y deseara un cambio.

En segundo lugar, trabajas en un equipo pequeño y es probable que valga la pena intentar que todo el equipo participe en la mejora de procesos.

Configura retrospectivas del proceso regular (por ejemplo, semanalmente). Tener todo el equipo:

• identificar problemas
• Ideas de voluntariado para mejorar las prácticas laborales
• Participar en la implementación de estas prácticas

Naturalmente, debe seguirse que todo el equipo también ayuda a garantizar el cumplimiento de las prácticas mejoradas.

Creo que has identificado un par de problemas:

1. Parece que cualquier código que se verifique puede ser trivialmente puesto en producción por cualquier persona que tenga los derechos para verificar el código.

Francamente creo que la configuración es una locura. Como mínimo, las personas que pueden activar manualmente un impulso a la producción deben estar restringidas al conjunto de personas en las que se puede confiar completamente para revisar y probar a fondo todos los cambios salientes (independientemente de quién haya creado los cambios) Antes de disparar el empuje. Darle a cualquier persona que tenga permiso para verificar el código el poder para desencadenar también arbitrariamente un impulso a la producción es solo pedir problemas. No solo de desarrolladores descuidados y / o incompetentes, sino también de los descontentos o terceros malintencionados que comprometen una de sus cuentas.

Y si va a utilizar un proceso de botón para implementar cada cambio que se registra, entonces necesita tener un conjunto completo de pruebas automatizadas en su lugar, y presionar el botón debe ejecutarlas (y abortar el despliegue si alguna prueba falla!). Su proceso no debe permitir que el código que ni siquiera se ha probado superficialmente alcance el punto en el que se implementa en el sistema de producción en primer lugar.

Su compañero de trabajo ha cometido un gran error en términos de verificar el código sin probarlo primero. Su organización ha cometido un error mucho más grande al adoptar un proceso de implementación que permite que el código no probado llegue a producción en cualquier circunstancia.

Por lo tanto, el primer orden de los negocios es arreglar el proceso de implementación. Limite quién puede desencadenar un impulso a la producción, o incorpore una cantidad razonable de pruebas en su proceso de implementación automatizada, o ambos.

2. Parece que es posible que no haya establecido estándares / principios de desarrollo claramente definidos.

En particular, parece que te falta una clara " definición de done " y / o el uso de uno que no incluya "el código ha sido probado" como un factor de activación al verificar el código en / implementar el código en producción. Si tuviera esto, en lugar de simplemente señalar que "el buen código no se produce de esta manera" podría decir "este código no cumple con los estándares mínimos que todos hemos acordado, y debe ser mejor en el futuro".

Debe intentar establecer una cultura que comunique claramente lo que se espera de los desarrolladores y los estándares y el nivel de calidad que deben respetar. La configuración de una definición de hecho que incluye al menos las pruebas manuales (o, preferiblemente, los casos de prueba automatizados que se pueden ejecutar como parte del proceso de compilación / implementación) ayudará con eso. Como puede tener consecuencias por romper la construcción. O consecuencias más severas por romper el sistema de producción. Tenga en cuenta que esas dos cosas deberían ser realmente independientes, y debería ser completamente imposible interrumpir tanto la compilación como el sistema de producción (porque las compilaciones dañadas nunca deberían ser implementables).

Debe integrar un proceso de Integración continua + Revisión por pares en la empresa. Bitbucket lo hace fácil.

Y +1 al servidor de desarrollo sugerido por otros usuarios.

No seas grosero con él, solo afectará tu relación laboral.