Mi compañero de trabajo se compromete y empuja sin probar


113

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.


1
Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .
Ingeniero mundial

55
Dado que está en Git, use solicitudes de extracción para aplicar revisiones de código antes de fusionarse con master y desplegarse en producción. Además, elimine sus credenciales para iniciar sesión en el servidor de implementación. Centralice esta autoridad en un no desarrollador. (El cumplimiento de PCI aplicado por la industria de las tarjetas de crédito requiere esto, por cierto.)
Barett

3
Desde el punto de vista del lugar de trabajo, si usted es un compañero de trabajo con esta persona y no de alguna manera su supervisor, no es probable que gane fuerza al 'castigarlos'. Concéntrese en mantener asegurada la calidad del código, no la retribución por los estándares laxos de su compañero de trabajo.
Zibbobz

2
¿Un impulso al repositorio "central" siempre desencadena una implementación de producción? Definitivamente no debería.
jpmc26

3
Leí la pregunta y me dije que el tipo debe ser turco y listo :) mira esto hermano: nvie.com/posts/a-successful-git-branching-model . Debe tener al menos dos ramas: master y dev donde los desarrolladores presionan solo para dev y después de probar se fusionan para masterizar e implementar.
Cemre

Respuestas:


92

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.


La idea de que Support realice el control de calidad cuando implica su lanzamiento a producción parece conveniente, pero no volará por el motivo de la separación de funciones. El soporte que es responsable del soporte más allá del final de las "pruebas de programadores" debería informarles sobre los cambios. Es realmente difícil con cuatro desarrolladores y nadie más :-) Si cambia su respuesta para aplicar directamente a la configuración del OP, entonces es no va a ser de mucha utilidad para nadie más ...
Bill Woodger

1
@BillWoodger ¿por qué? Para ellos es un sistema de 'cambios futuros y reversión'. No solo obtienen el beneficio de ver lo que viene antes de que se `` vuelva real '', sino que también es una forma de retroceder a la última versión fácilmente si las cosas van mal. No olvide que la puesta en escena es la prueba de fin de programador.
gbjbaanb

1
@gbjbaanb porque coloca a Soporte en la misma posición y restablece el problema original. El soporte generalmente tendría acceso de emergencia a Producción. Si también tienen otro acceso, tiene problemas de auditoría (si eso es importante). Si alguien puede cambiar algo, entonces hay un problema. Por supuesto, el Soporte debe saberlo todo, no deberían poder hacerlo todo. Eso es lo que dice cada auditor con el que he estado involucrado, y me convencieron de esto hace mucho tiempo.
Bill Woodger

@BillWoodger No estoy seguro de lo que estás diciendo. Los equipos de producción que conozco generalmente tienen sus propios procesos de implementación que incluyen un entorno de prueba (solo para verificar si hay errores tontos primero). En un equipo pequeño, no hay razón por la cual este sistema de prueba no pueda ser compartido por el desarrollador y el soporte. De todos modos, no se permiten cambios: está lleno por dev a través de la automatización y consumido por el soporte. No es diferente a darles un código postal del mismo código. Los auditores están interesados ​​en los procesos, no en la implementación de esos procesos (excepto que se siguen, por supuesto)
gbjbaanb

1
Los auditores de @gbjbaanb se preocupan de que las personas tengan acceso a todo. Si un tipo de Soporte puede cambiar un programa en Desarrollo y ponerlo en Producción sin intervención de nadie más, entonces el sistema está expuesto. Claro, con las cuatro personas de OP no hay un "Soporte" separado de todos modos, y una división satisfactoria de la función será difícil.
Bill Woodger

54

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.


10
+1 para la conversación. Tiene que haber un entendimiento compartido de que este es un problema y por qué es un problema. Solo entonces puede haber algún éxito con una solución técnica.
Patrick

99
+1 para obtener servidores de desarrollo / entornos de ensayo. Hasta que haya un lugar real fuera de la propia máquina para impulsar las cosas, este comportamiento no es completamente culpa del compañero de trabajo. Solo hay mucho que una persona puede hacer en su propia máquina, y si nada más, el entorno adicional a menudo ayuda con un cambio en el proceso de pensamiento / actitud en la prueba.
Joel Coehoorn

20

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.


17

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.


1
Realmente no tengo claro cómo "comprometer / impulsar, implementar en producción inmediatamente y probar sus cambios allí y en ningún otro lugar" es una mentalidad SVN ... La única parte de ese proceso que involucraría a SVN es el compromiso. Incluso con un modelo de sucursal única o control de fuente, una confirmación no implica necesariamente una implementación de producción. O al menos, no debería.
jpmc26

@ jpmc26: A riesgo de una guerra de fuego Git / SVN: Heredamos un sistema SVN para gran parte de nuestro código "heredado" pero hemos estado usando Git para nuestro trabajo más reciente. Casi puedo garantizar que no teníamos la configuración SVN correcta y / o no la estábamos usando correctamente, pero el manejo de las ramas por parte de Git parece mucho más fácil de trabajar. Estoy 100% seguro de que SVN es más que capaz de manejar una implementación adecuada, pero también puedo ver (desde mi experiencia imperfecta) cómo SVN podría "disuadirlo menos" de hacer lo correcto. En cualquier caso, esto solo sería un factor contribuyente y la educación del usuario es más importante.
TripeHound

1
@TripeHound Ningún argumento sobre el sistema git es en general mejor para administrar los cambios de código. (Mis objeciones con git generalmente tienen que ver con la curva de alto aprendizaje). Mi punto es más que, si bien git puede tener más capacidades para ayudarlo a administrar su proceso de lanzamiento, la forma en que configura su infraestructura de compilación sigue siendo el factor principal sobre su elección del control de fuente. Tuve una automatización de creación y lanzamiento bastante exitosa en SVN durante bastante tiempo, por lo que no tengo muy claro qué es una "mentalidad SVN" o cómo afecta negativamente su lanzamiento.
jpmc26

2
El hecho de que se comprometa a dominar no significa que deba implementarlo en producción. Incluso si su repositorio de origen / svn repo está alojado en el servidor de productos, esto no implica tal cosa.
vonPetrushev

12

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.


2
Esto solo funciona con una oficina. ¿Cuál es el concepto equivalente para cuando tienes un equipo distribuido de desarrolladores remotos que trabajan desde casa?
Aroth

2
@aroth Para algunos equipos, un simple correo electrónico de la persona que rompió la construcción es suficiente. Planifíquelo como un "objetivo de mejora continua del proceso" y solicite que el correo electrónico contenga suficiente información para que otros puedan ver qué salió mal, por qué salió mal y qué cambiará esa persona sobre su proceso, o qué están sugiriendo sobre el cambio del equipo. el proceso, para evitar que vuelva a suceder. La mayoría de las personas odian los informes y los informes, y de nuevo es bastante molesto que puedan tener más cuidado de no romper la construcción en el futuro.
Adam Davis

8

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.


6

¿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.


"¿Tiene copias de seguridad que sean lo suficientemente buenas", y, de ser así, ¿su colega quiere ser el muggins que tiene que restaurar la copia de seguridad porque rompió el servidor? Quizás, en principio , le gustaría probar antes de implementar, pero dado que no hay un entorno de prueba, está tomando la opción más fácil actualmente disponible. Entonces, hacer el caso de un servidor de prueba debería ser fácil. Por cierto, los errores que no se detectan "durante bastante tiempo" pasarán por la prueba hasta la implementación, ya que el problema de dichos errores es la calidad de las pruebas, no dónde se realizan las pruebas.
Steve Jessop

No solo tiene las copias de seguridad, sino que también su empresa puede permitirse el tiempo de inactividad mientras se realiza una restauración. ¿Y puede permitirse perder minutos, horas o incluso días de información porque se tuvo que realizar una reversión de la base de datos? Yo diría que en casi todos los casos no triviales, la respuesta es un rotundo 'no'. E incluso en casos triviales, no desea que "restaurar una copia de seguridad" sea la forma en que maneja el código no probado que se registra. Tiene que haber algo que garantice que las pruebas se realicen entre el momento en que se registra el código y cuando llega a la producción.
Aroth

Totalmente de acuerdo, por eso le dije "pregúntale a tu desarrollador qué piensa al respecto". Está totalmente engañado y cree que su código está libre de errores, o no se da cuenta del daño que puede causar. O tercera posibilidad, él lo sabe y no le importa.
gnasher729

3

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.


¡Una retrospectiva es una excelente manera de abordar y, con suerte, cambiar ese comportamiento de una manera constructiva!
greenSocksRock

1

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.

  1. 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).


0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.