El documento habla sobre las integraciones continuas, que implica que los miembros del equipo integran su código diariamente para detectar errores tempranamente. Esto ayuda a reducir problemas de integración y permite desarrollar software más rápido. Las integraciones continuas involucran poner el código en un repositorio central y automatizar el proceso de compilación.

1. CENSURADO

2. ¿Qué es?
Es la práctica de desarrollo de software donde los miembros de un equipo integran su
código continuamente, Usualmente una persona integra al menos una vez al día pero pueden
ser multiples veces en un solo día. Cada integración es verificada por una construcción
automática “Automated Build” para detectar errores de integración tan rápido como sea
posible. Muchos equipos encuentran que está práctica los ayuda a reducir muchos problemas
de integración tempranamente y le permite a los equipos desarrollar software más
rapidamente.
Martin Fowler

3. Construcciones diarias – “Daily Builds”
Poner el código en un solo lugar donde todos puedan accederlo. (CVS y Visual SourceSafe)
Automatizar el proceso de construcción de tal manera que se pueda hacer con un solo
comando o con una herramienta. (Ant, Nant, Team Foundation Server Team Build,
CruiseControl, CruiseControl.NET)

4. Breve resumen
“Test Driven Development”

5. Test Driven Development
Un método para dividir un problema en pequeñas partes.
Es Probar, Desarrollar, Diseñar, Repetir.
TDD es el proceso de pensar acerca de un bloque de código desde la perspectiva del usuario que usará
el código.
TDD es esencial para los proyectos con metodología XP, pero esto no significa que solo se pueda usar
en estos proyectos.
Escribir una prueba que muestre lo que usted quiere que haga el código, antes de escribirlo.
Su base de código ira creciendo mientras realiza el desarrollo de las pruebas unitarias.
“TDD es una técnica poderosa para producir código bien diseñado con menos defectos”. Martin Fowler

6. Como lo hacemos?
Nos basamos en los casos de prueba, en base a estos empezamos a desarrollar las pruebas
unitarias.
Escribimos el código más sencillo posible para que los casos de prueba se ejecuten
satisfactoriamente.
Escribimos pruebas que fallen y empezamos a hacer refactoring hasta que todas los casos de
pruebas sean satisfactorios.
Aplicamos refactoring en el camino.

7. Ejemplo código de la prueba unitaria
[Test]
public void TestPolicy()
{
private CPasswordManager hash = new CPasswordManager();
Assert.IsTrue(hash.MeetsPasswordPolicy("goodpass"),
"Good password failed check");
Assert.IsFalse(hash.MeetsPasswordPolicy("badpass"),
"Bad password passed check");
}
7

8. Ejemplo del código de la aplicación
public bool MeetsPasswordPolicy(string password)
{
bool meetsPolicy = false;
//NOTE: this policy is too simple; should probably be a
// regular expression, checking for length and mandatory
// character types
if(password.Length >= 8)
meetsPolicy = true;
return meetsPolicy;
}

9. Continuación IC

10. Buenas prácticas
Uso de un repositorio de control de código fuente.
Uso de una herramienta de automatización de builds.
Los errores deben ser revisados exactamente después de las construcciones.
“Automatizar el proceso de pruebas de unidad. Se recomienda construir pruebas
unitarias antes de hacer el código, ya que al realizar el proceso automático de
construcción se puede configurar no solo que haga la construcción, si no también que
se ejecuten las pruebas unitarias, en otras palabras utilizar Test Driven Development.”
SQA solo debe probar sobre Builds exitosos.
Entre más regulares sean los Builds, mejor.
Ejemplo:
Cada que se haga check-in de un artefacto.
Cada 2 horas.
Cada que se construya una funcionalidad completa.

11. Beneficios
Detección temprana de errores.
Automatización de las pruebas unitarias.
Análisis de código estático en las construcciones.
Rápida solución de errores.
Reducción de tiempo de desarrollo.
11

12. What makes a Successful Build?
El último código fuente de los desarrolladores ha sido subido al control de código.
Todos los archivos de la integración han sido compilados.
Todos los objetos, ejecutables, dll, jars del resultado de la compilación pueden ser usados
inmediatamente.
Una suite de pruebas de unidad ha sido ejecutada contra el código en cuestión.
Si todo esto ocurre sin intervención humana y el Build sale sin errores, entonces tenemos
un Build exitoso.
12

13. ScreenShots - CruiseControl

14. ScreenShots - CruiseControl

15. ScreenShots - CruiseControl

16. ScreenShots - CruiseControl

17. ScreenShots - CruiseControl

18. ScreenShots - CruiseControl

19. ScreenShots – Team Foundation build

20. ScreenShots – Team Foundation build