continuous integration - philip - Construcción diaria frente a cero defecto
philip crosby aportaciones (11)
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 administrar los defectos. Si el defecto es un show-stopping entonces seguro, es probable que no quieras registrarlo, pero si se trata de algo menor o un caso marginal, entonces puede tener sentido verificarlo con el defecto conocido, siempre y cuando volver a rastrearlo.
Permitir que los defectos existan le permite enfocarse en cosas más importantes; por ejemplo, si solo tiene una cantidad limitada de tiempo en un lanzamiento, es posible que no tenga tiempo para arreglar todo y para obtener toda la funcionalidad, de modo que si es una elección entre arreglar diez errores menores en el borde del caso, o la creación de una pieza de funcionalidad para agregar valor, entonces la elección pragmática puede ser enviar errores conocidos.
No digo que cero defectos es una mala idea, de hecho, nos esforzamos por lograr esto al final de cada ciclo de lanzamiento, pero, como muchas otras cosas en el desarrollo de software, el pragmatismo normalmente funciona mejor en el mundo real que el puritanismo.
¿Cómo se hace una compilación diaria y se lucha por un entorno sin defectos? ¿Significa que nunca podré irme a casa hasta que haya matado a todos los errores en mi nuevo código? ¿O significa que no reviso mi código hasta que lo he probado por completo, lo que deja el código ramificado de manera efectiva durante mucho más tiempo?
Estoy trabajando con un puñado de programadores por primera vez (en lugar de trabajar solo o con otro codificador), así que estoy luchando con decisiones como esta por primera vez. ¿Deberíamos adoptar un proceso de desarrollo de software?
El truco es hacer el check-in tan a menudo como sea posible, solo hacer que pasen algunas pruebas, ¡compruébalo! Se corrigió un error, ¡compruébalo! ¡Intenta encontrar el incremento más pequeño posible y compruébalo! Esto tiene el beneficio adicional de hacer que sea posible y convincente escribir comentarios que realmente son relevantes, por lo que es una buena ventaja.
Por supuesto, eso requiere que tengas un entorno de CI que crees más a menudo que las noches, siempre que sea posible es la mejor opción.
Ah, y recuerda, si nunca se rompe, entonces lo estás haciendo mal. (Es decir, eres demasiado conservador, un poco de rotura de vez en cuando solo demuestra que esperas poder hacerlo).
Integre temprano, integre a menudo, integre rápidamente. En lugar de una "creación diaria", compila cada vez que alguien se comprometa y se comprometa a menudo (al menos una vez al día, preferiblemente más de 2).
Importante: la retroalimentación rápida es necesaria para defectos menores. Si su construcción lleva muchos minutos o incluso más de una hora, eventualmente odiará la construcción, aprenderá a evitarla, la ejecutará lo menos posible, etc. Su valor se reduce rápidamente hasta el punto de no tener valor y su conteo de defectos comienza a dispararse.
Invierta un tiempo por adelantado para que su compilación funcione rápidamente. Si hay cosas lentas, descubre por qué es lento y elimina eso. Si no puede, al menos configure una construcción en cascada para que el resto de la construcción sea rápido (piense en <2-5 minutos) y las cosas de larga duración pueden seguir inmediatamente y tomar el tiempo que quiera (aunque intente para mantenerlo por debajo de 10m tops).
No puedo decir lo suficiente: ¡el ciclo de retroalimentación rápido sobre los cambios es extremadamente importante!
Me gustaría ir con @feverentcoder en los argumentos de CI. CI es tu amigo, ¡deja que te ayude!
En cuanto al punto de Branch / Trunk, todos deberían trabajar siempre en el trunk , las sucursales son para spikes y POCs, etiquetar todas las versiones
Cuando se trata de procesos, generalmente es beneficioso encontrar prácticas que sean relevantes para usted y luego crear 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 semana o dos para ver si funciona contigo; si no lo hace, tíralo. ¡Acabas de aprender una forma más de no hacer una bombilla!
Sí, adopte un proceso de desarrollo de software. Hay una variedad, de la cual estoy seguro que más de una se ajustará a su equipo. Incluso uno que no es una pareja perfecta es mucho mejor que ningún proceso en absoluto.
Entonces, ¿cómo hace mi empresa para tener construcciones diarias y luchar por cero defectos? Ejecutamos nuestro conjunto de pruebas antes de verificar nuestro código. El único problema 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, realizamos una serie de pruebas que demoran aproximadamente 8 horas en ejecutarse. Luego, los fines de semana, ejecutamos el conjunto completo de pruebas. Cada etapa capta más y más problemas, pero más del 90% se detectan con las pruebas de desarrollador de 5 minutos y probablemente más del 98% con las pruebas nocturnas. Esto todavía nos alerta bastante temprano de los problemas antes de que lleguen a nuestros clientes y cuestan mucho solucionarlos.
Si no va a su casa hasta que se hayan ido todos sus defectos, entonces nunca se irá a casa.
Mi opinión sobre esto es que la compilación diaria debe automatizarse en ciertos momentos. Cualquier código no registrado antes de que esto no se genere y si no hay registros de alguien durante 2 días (compilaciones) en una fila, entonces el sistema de compilación debe notificarles a ellos y al líder técnico ya que esto es una señal de advertencia.
Significa hacer commit mucho más pequeños. Cuantas más veces cometa revisiones de trabajo, con menor frecuencia su propia copia de trabajo se rompe. El desarrollo iterativo comienza contigo.
Un enfoque quizás más pragmático es tener cero defectos en el tronco y ramificarse para todo desarrollo, luego tener compilaciones diarias es posible 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 al hacer que su rama rompa sus construcciones, es menos problemático que romper el tronco.
Al mirar a través de 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, entiendo que las herramientas como CruiseControl son útiles, pero, como dijo Jim Shore, la integración continua es una actitud, no una herramienta . Es el compromiso grupal de mantener el código funcionando lo que es clave.
Acerca de la estrategia de cero defectos: puede irse a casa, si hay errores conocidos en su código. Se trata más bien de que los defectos se reparen antes de que se implementen 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 estos desarrolladores deben crear.
Simple: nunca ingrese el código con errores (conocidos) en él. Esto no significa que debes registrarte una vez al día. Controle cuando tenga implementado un cambio significativo para que los otros desarrolladores puedan tener acceso a él.
Siempre nos integramos localmente, ejecutamos nuestras pruebas en contra del código, y cuando todos los pases, nos registramos. Reviso entre 20 y 30 veces al día cuando trabajo. El servidor de compilación recoge cambios y ejecuta compilaciones contra el sistema. La integración continua (CI) es algo bueno. :RE
Integración continua: automatice sus compilaciones
Comience construyendo exitosamente y manténgalo así tanto como sea posible. Es esencial en un ambiente 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 inadvertidamente verificaste algo malo, y dejas de hacer lo que estás haciendo para que la estructura vuelva a estar verde. Un servidor de compilación que nunca tiene construcciones rotas es una señal de advertencia.
También estoy de acuerdo con la respuesta de chammyers: lo que usted decida, debe ser automático y automatizado. Lo mejor de la automatización de herramientas para hacer este tipo de cosas para usted es que ya no tiene que pensar en eso o recordar hacerlo. O como dijo Chad, no dejes de hacerlo. Podría recomendar 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 tienes CI, puedes obtener una calidad superior si puedes inyectar algo de humor (y vergüenza) al introducir un token de construcción roto. http://ferventcoder.com/archive/2008/08/20/continuous-integration-enhancement--the-broken-build-token.aspx
Use una buena herramienta para compilaciones automatizadas
La mayoría de las personas en .NET land usan scripts NAnt o MSBuild para tener compilaciones automatizadas que luego pueden conectar a su servidor de CI. Si recién está comenzando, mi sugerencia sería usar UppercuT , es un framework de construcción insanamente fácil de usar que usa NAnt. Aquí hay un segundo enlace con explicaciones más profundas: UppercuT .
Sucursales vs tronco para el desarrollo activo
No tendrías que ramificar a menos que dejes la cajuela abierta solo para las entregas (lo que significa que todos los demás trabajan en la misma rama que tú). Pero tendría CI en el tronco y 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 sí rotundo. Pero no se apresure a nada a menos que se requiera un cambio drástico. Elija un proceso al que desee migrar y lentamente empiece a adoptar procesos. Y evaluar, evaluar, evaluar. Si el proceso particular no funciona para su grupo, averigüe si está haciendo algo mal o si solo necesita eliminarlo. Y luego hazlo Cualquier proceso que acabe necesita funcionar para usted o no funcionará.