Cuando mi compañero de trabajo piensa que no hay necesidad de una prueba en su PC, hace cambios, se compromete y luego empuja. Luego prueba en el servidor de producción y se da cuenta de que cometió un error. Sucede una vez en una semana. Ahora veo que hizo 3 confirmaciones y empuja con la implementación al servidor de producción en 5 minutos.

Le dije pocas veces que esta no es la forma en que se hace un buen trabajo. No quiero volver a ser grosero con él y él está en el mismo estado que yo en la compañía y ha trabajado más que yo aquí.

Quiero que este comportamiento sea castigado de alguna manera o que sea lo más desagradable posible.

Antes de comenzar, la compañía estaba implementando métodos antiguos, como FTP, y no había control de versiones.

Los forcé a nosotros / nosotros a usar Git, Bitbucket, Dploy.io y HipChat. La implementación no es automática, alguien debe iniciar sesión en dply.io y presionar el botón de implementación.

Ahora, ¿cómo puedo obligarlos a no probar en el servidor de producción? Algo así como el robot HipChat puede sentir que hay ediciones repetidas en la misma línea y enviar un aviso al programador.

Necesita un proceso de garantía de calidad (QA) adecuado.

En un equipo profesional de desarrollo de software, no se pasa del desarrollo a la producción. Tiene al menos tres entornos separados: desarrollo, puesta en escena y producción.

Cuando crees que tienes algo funcionando en tu entorno de desarrollo, primero te pones en escena, donde el equipo de control de calidad prueba cada confirmación, y solo si esa prueba es exitosa, pasa a producción. Idealmente, el desarrollo, las pruebas y el impulso a la producción son realizados por personas separadas. Esto se puede garantizar configurando su sistema de automatización de compilación de una 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 implementar 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 desde el desarrollo hasta la puesta en escena y desde la puesta en escena hasta la producción, pero no hacer ambas cosas para la misma compilación, por lo que una segunda persona siempre es requerido (pero asegúrese 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 haga 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 garantizarles algo de trabajo a largo plazo.

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.

En el trabajo, evitamos esto usando Gerrit . Gerrit es un sistema de revisión de código que actúa como una puerta a su rama Git principal / de producción que se llama convencionalmente "maestro". Tienes revisiones de código, ¿verdad? Parece que personalmente los haces excepcionalmente. Con Gerrit, se pasa a una especie de rama provisional que, después de que usted y su compañero de trabajo hayan ejecutado satisfactoriamente el proceso de revisión del código, Gerrit se fusiona con su rama maestra. 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 en el que pueda configurar una herramienta de CI, Codeship tiene un buen plan gratuito para usar como prueba de concepto.

Lo último, por supuesto, es automatizar las implementaciones de producción solo a partir de productos de construcción sancionados que hayan sobrevivido a la revisión del código y las pruebas unitarias. Hay algunas tecnologías interesantes para esto, que no mencionaré por temor a que sea un cebo de llamas.

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 medida 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 sea bastante posible que el desarrollador en cuestión solo esté atrapado en una mentalidad SVN , y bien puede pensar que está siguiendo el proceso.

Considero que la mejor manera de abordar este tipo de problema, especialmente cuando puede no haber un superior claro, no gira en torno al castigo o la eliminación del acceso; esto solo conduce al resentimiento y, como parece, eres el gran defensor de seguir el proceso (siempre hay uno, y he sido 'ese tipo' antes), es probable que seas el que más calor genere. 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 cada vez (y puede comenzar a presentar la idea de un entorno de ensayo aquí también). No debería ser difícil, y es muy sensato. Luego, pida al equipo que proponga algunas reglas sólidas sobre cómo se debe hacer. Cuanto más contribuya el desarrollador que está causando el problema, más ganas tendrá de cumplir con las reglas y comenzará a ver por qué su comportamiento ha sido un problema.

El punto final, es nunca caer en el "bien, ¡es mejor de lo que solía ser!" trampa. Siempre hay margen de mejora. 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. La solución continúa, hasta que de repente estás en un punto de crisis nuevamente.

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

Rompe la construcción, trae donas.

Ya sea 1) obtendrá donas dos veces por semana o 2) se adherirán al estándar.

Tráelo en una reunión. No es acusador, no mencione a nadie por su nombre, sino por algo similar a "Desde que introdujimos el control de versiones y los estándares de implementación, las cosas se han vuelto mucho más fáciles y el servidor está funcionando más tiempo de lo que solía ser. ¡Esto es genial! Sin embargo, todavía es tentador tomar un atajo y enviarlo sin una prueba adecuada. 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 rompa el servidor, la persona responsable interviene donas para el equipo al día siguiente ".

Sustituya las donas por algo más, si lo desea, y no lo haga costoso: el almuerzo para todo el equipo sería demasiado, pero una caja de donas de $ 5 o una bandeja de frutas / verduras, o papas fritas y salsa, etc., etc. probablemente sería molesto lo suficiente como para que realmente comparen el riesgo con la conveniencia de saltarse las pruebas sin que sea una carga que los aleje del equipo o la empresa.

Ahora, ¿cómo puedo forzarlos ...

En lugar de obligar 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 lo más desagradable posible.

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

Si tiene éxito con esto, sacará lo mejor de él y él encontrará soluciones al problema en el que nunca pensó.

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

¿Que es lo peor que puede pasar? ¿Tiene copias de seguridad que sean lo suficientemente buenas como para que un error que modifica los registros aleatorios en su base de datos pueda repararse restaurando una versión anterior?

Supongamos que tiene un error en el que utiliza una identificación de registro y, por error, la cantidad de una factura en centavos se almacena en una variable utilizada para la identificación del registro. Entonces, si pago $ 12.34, el registro con la identificación 1234 se modificará. ¿Puede recuperarse de eso si el software se ejecuta durante unas horas hasta que se detecta el error? (Si se actualizan tanto el registro correcto como el registro 1234, solo lo detectará 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 sobre esto. Obviamente, no puede afirmar que nunca comete errores, porque lo ha hecho en el pasado.

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

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

En primer lugar, hablaría en voz baja con el fundador para asegurarme de que él / ella está de acuerdo con su punto de vista. Si hay un corte de producción, esperaría que el fundador esté muy preocupado por eso y desee un cambio.

En segundo lugar, trabajas en un equipo pequeño y es probable que valga la pena tratar de involucrar a todo el equipo en la mejora del proceso.

Configure retrospectivas de procesos regulares (por ejemplo, semanales). Tener todo el equipo:

• Identificar problemas
• Ideas voluntarias para mejorar las prácticas laborales.
• Participar en la implementación de esas prácticas

Debe seguir naturalmente 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 impulsado a la producción por cualquiera que tenga los derechos para registrar 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 restringirse al conjunto de personas en las que se puede confiar por completo para revisar y probar a fondo todos los cambios salientes (independientemente de quién haya creado los cambios) antes de activar el impulso. Darle a cualquiera con permiso para registrar el código el poder de desencadenar arbitrariamente un impulso a la producción es solo pedir problemas. No solo de desarrolladores descuidados o incompetentes, sino también de personas descontentas o de terceros maliciosos que comprometen una de sus cuentas.

Y si va a utilizar un proceso de botón para desplegar cada cambio que se registra, entonces necesita tener un conjunto completo de pruebas automatizadas, y presionar el botón necesita ejecutarlas (y abortar la implementación si cualquier prueba falla! Su proceso no debe permitir que el código que ni siquiera ha sido probado superficialmente llegue al punto donde se está implementando en el sistema de producción en primer lugar.

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

Entonces, el primer orden del día 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 ambas cosas.

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

En particular, parece que le falta una clara " definición de hecho ", y / o el uso de una que no incluya "el código ha sido probado" como un factor clave en el registro de código / implementación de código en producción. Si tuviera esto, en lugar de señalar que "un 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 mantener. Establecer una definición de hecho que incluya al menos pruebas manuales (o preferiblemente, casos de prueba automatizados que se pueden ejecutar como parte del proceso de construcció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 realmente deberían ser independientes, y debería ser completamente imposible romper tanto la compilación como el sistema de producción al mismo tiempo (porque las compilaciones rotas nunca deberían ser implementables).

Debe integrar un proceso de Continuous Integration + Peer Review en la empresa. Bitbucket lo hace fácil.

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

No seas grosero con él, solo dañará tu relación laboral.