Construcción diaria vs. defecto cero

Question

¿Cómo se realiza una compilación diaria y se esfuerza por lograr un entorno sin defectos? ¿Significa que nunca podré volver a casa hasta que haya eliminado todos los errores en mi nuevo código? ¿O significa que simplemente no vuelvo a registrar mi código hasta que lo haya probado completamente, lo que deja el código efectivamente ramificado durante mucho más tiempo?

Estoy trabajando con un puñado de programadores por primera vez (en lugar de trabajar solo, o solo con otro programador), así que estoy luchando con decisiones como esta por primera vez. ¿Deberíamos adoptar un proceso de desarrollo de software?

Answer 1

Sí, adopte un proceso de desarrollo de software. Existe una gran variedad, de la cual estoy seguro de que más de uno se ajustará a su equipo. Incluso uno que no sea una combinación perfecta es mucho mejor que ningún proceso.

Entonces, ¿cómo hace mi empresa para tener compilaciones diarias y luchar por cero defectos? Ejecutamos nuestro conjunto de pruebas antes de registrar nuestro código. El problema único para nosotros es que una ejecución completa de nuestro conjunto de pruebas lleva más de 72 horas, por lo que ejecutamos un conjunto limitado de pruebas unitarias antes de registrar el código. Para nuestras compilaciones nocturnas, ejecutamos un conjunto de pruebas que demoran aproximadamente 8 horas en ejecutarse. Luego, los fines de semana ejecutamos el conjunto de pruebas completo. Cada etapa detecta más y más problemas, pero más del 90% se detecta con las pruebas de desarrollo de 5 minutos y probablemente más del 98% con las pruebas nocturnas. Esto todavía nos alerta bastante pronto sobre los problemas antes de que lleguen a nuestros clientes y cuesten mucho solucionarlos.

Answer 2

Simple: nunca verifique el código con errores (conocidos) . Esto no significa que se registre una vez al día. Regístrese cuando haya implementado un cambio significativo para que los otros desarrolladores puedan acceder a él.

Siempre nos integramos localmente, ejecutamos nuestras pruebas contra el código, y cuando todo pasa, nos registramos. Me registro aproximadamente 20-30 veces al día cuando estoy trabajando. El servidor de compilación recoge los cambios y ejecuta compilaciones contra el sistema. La integración continua (CI) es algo bueno. : D

Integración continua: automatice sus compilaciones

Comience a construir con éxito y manténgalo así tanto como sea posible. Es esencial en un entorno de equipo. Solo recuerda que las compilaciones se romperán. Se espera que se rompan de vez en cuando. Es una señal de que, sin darse cuenta, ha registrado algo malo y detiene lo que está haciendo para que la construcción vuelva a ser verde. ¡Un servidor de compilación que nunca tiene compilaciones rotas es una señal de advertencia!

También estoy de acuerdo con la respuesta de chadmyers: sea lo que sea que decidas, debe ser automático y automatizado. Lo mejor de automatizar herramientas para hacer este tipo de cosas por usted es que ya no tiene que pensar en ello ni recordar hacerlo. O como dijo Chad, no dejas de hacerlo. Podría recomendar hacer una recomendación para las herramientas de CI, pero eche un vistazo aquí: ¿Qué herramientas utiliza para las compilaciones automatizadas / implementaciones automatizadas? ¿Por qué?

Una vez que tiene CI, puede obtener una mayor calidad si puede inyectar algo de humor (y vergüenza) al introducir un token de construcción roto http: // ferventcoder .com / archive / 2008/08/20 / continuo-integración-mejora - the-broken-build-token.aspx

Use una buena herramienta para compilaciones automatizadas

La mayoría de las personas en tierra .NET usan scripts NAnt o MSBuild para tener compilaciones automatizadas que luego pueden conectar a su servidor CI. Si recién está comenzando, mi sugerencia sería usar UppercuT , es una locura Marco de compilación fácil de usar que utiliza NAnt. Aquí hay un segundo enlace con explicaciones más profundas: UppercuT .

Ramas vs Troncal para desarrollo activo

No tendría que ramificarse a menos que deje la troncal abierta solo para versiones (lo que significa que todos los demás están trabajando en la misma rama que usted). Pero tendría CI tanto en el tronco como en la rama de desarrollo activo.

Proceso de desarrollo de software

También para responder la pregunta sobre un proceso de desarrollo de software, la respuesta es un rotundo sí. Pero no se apresure a nada a menos que se requiera un cambio drástico. Elija un proceso hacia el que desee migrar y comience a adoptar lentamente los procesos. Y evaluar, evaluar, evaluar. Si el proceso en particular no funciona para su grupo, averigüe si está haciendo algo mal o si solo necesita eliminarlo. Y luego hazlo. Cualquier proceso con el que termine necesita trabajar para usted o no funcionará.

Answer 3

Significa hacer commits mucho más pequeños. Cuanto más a menudo realice revisiones de trabajo, con menos frecuencia se romperá su propia copia de trabajo. El desarrollo iterativo comienza contigo.

Answer 4

Integre temprano, integre a menudo, integre rápido. En lugar de una 'construcción diaria', construya cada vez que alguien se compromete y se compromete a menudo (al menos una vez al día, preferiblemente más de 2).

Importante: es necesaria una respuesta rápida para defectos bajos. Si su construcción toma muchos minutos o incluso más de una hora, eventualmente crecerá para odiarla, aprender a evitarla, ejecutarla lo menos posible, etc. Su valor cae rápidamente hasta el punto de no tener valor y su conteo de defectos disminuirá. comenzar a dispararse.

Invierte un poco de tiempo para que tu construcción funcione rápidamente. Si hay cosas lentas, descubra por qué son lentas y elimínelas. Si no puede, al menos configure una compilación en cascada para que el resto de la compilación vaya rápido (piense & Lt; 2-5 minutos) y las cosas de larga duración pueden seguir inmediatamente y tomar todo el tiempo que sea necesario. quiere (aunque trate de mantenerlo por debajo de 10 m como máximo).

No puedo decirlo lo suficiente: ¡el ciclo de retroalimentación rápida sobre los cambios es extremadamente importante!

Answer 5

El truco es hacer el check-in con la mayor frecuencia posible, solo hice pasar algunas pruebas, ¡buen check-in! Se corrigió un error, ¡revísalo! ¡Intenta encontrar el incremento más pequeño posible y compruébalo! Esto tiene el beneficio adicional de hacer posible y conveniente escribir comentarios de registro que realmente sean relevantes, por lo que es una buena ventaja.

Por supuesto, eso requiere que tenga un entorno de CI que se desarrolle con más frecuencia que las noches, tan a menudo como sea posible, realmente es la mejor opción allí.

Ah, y recuerda, si nunca se rompe, entonces lo estás haciendo mal. (Es decir, estás siendo demasiado conservador, un poco de ruptura de vez en cuando solo demuestra que, con suerte, lo estás presionando).

Answer 6

Si no te vas a casa hasta que todos tus defectos hayan desaparecido, nunca volverás a casa.

Mi opinión al respecto es que la compilación diaria debe automatizarse en ciertos momentos. Cualquier código que no se haya registrado antes de esto no se construye y si no hay registros de alguien durante 2 días (compilaciones) seguidas, el sistema de compilación debe notificárselo a ellos y al líder técnico, ya que esta es una señal de advertencia.

Answer 7

Un enfoque quizás más pragmático es tener cero defectos en el tronco y ramificar para todo el desarrollo, luego es posible tener construcciones diarias tanto en el tronco como en las ramas, pero cero defectos no se aplica a las ramas de desarrollo.

Si bien puede haber un cierto nivel de estigma debido a que su rama rompe sus compilaciones, es menos problemático que romper el tronco.

Answer 8

Mirando las respuestas, me sorprende que nadie haya mencionado Test Driven Development. Si su objetivo es cero defectos, ese es el mejor lugar para comenzar.

Después de eso, recomendaría encarecidamente la programación de pares.

Finalmente entienda que herramientas como CruiseControl son útiles pero, como dijo Jim Shore, la integración continua es una actitud, no una herramienta . La clave es el compromiso del grupo de mantener el código funcionando.

Answer 9

Acerca de la estrategia de cero defectos: puede irse a casa, si hay errores conocidos en su código. Se trata más de que los defectos deben repararse antes de implementar nuevas funciones.

Eso no debe aplicarse a todo el equipo, pero si un desarrollador tiene un error asignado, ese error tiene prioridad sobre las nuevas características que este desarrollador debe crear.

Answer 10

Dependiendo de lo que esté construyendo, adoptar un enfoque de que los defectos no están permitidos puede no ser apropiado. Mi opinión personal es que rara vez, si alguna vez lo es.

El objetivo de un sistema de gestión de defectos es exactamente eso: permitirle gestionar defectos. Si el defecto es un show-stop, entonces seguro, probablemente no desee registrarlo, pero si es algo menor o un caso extremo, entonces puede tener sentido registrarlo con el defecto conocido siempre que usted ' volver a rastrearlo.

Permitir que existan defectos le permite enfocarse en cosas más importantes; por ejemplo, si solo tiene una cantidad limitada de tiempo en una versión, es posible que no tenga tiempo para arreglar todo y obtener toda la funcionalidad, así que si es un elección entre corregir diez errores menores de caja de borde, o crear una pieza de funcionalidad de valor agregado, entonces la opción pragmática puede ser enviar con errores conocidos.

No digo que cero defectos sea una mala idea, de hecho, nos esforzamos por lograrlo al final de cada ciclo de lanzamiento, pero como muchas cosas en el desarrollo de software, el pragmatismo normalmente funciona mejor en el mundo real que el puritanismo.

Answer 11

Me gustaría ir con @feverentcoder en los argumentos de CI. ¡CI es tu amigo, deja que te ayude!

En cuanto al punto de Rama / Troncal: todos deben trabajar siempre en el tronco , rama es para picos y POC, etiqueta todos lanzamientos

Cuando se trata de procesos, generalmente es beneficioso encontrar prácticas que sean relevantes para usted y luego construir microprocesos a su alrededor. Además, use solo aquellas prácticas / procesos que considere que mejoran la productividad. Por último, sé valiente: prueba una práctica durante una o dos semanas para ver si funciona contigo; si no es así, tíralo a la basura. ¡Acabas de aprender una forma más de no hacer una bombilla!