2. Quality means doing it right when no one is looking.
—Henry Ford
In this chapter, we cover risks that CI can mitigate,
such as late discovery of defects, lack of project
visibility, low-quality software, and the inability to
create deployable software.
3. CI helps you identify and mitigate risks when they
occur, making it easier to evaluate and report on the
health of the project based on concrete evidence
4. How much of the software have we implemented?
Answer: Check the latest build
How much test coverage do we have?
Answer: Check the latest build
Who checked in the latest code?
Answer: Check the latest build
5. Using CI, you can build a
“quality safety net” and
deliver software faster. When
you press the “Integrate
button” at every change, you
build a foundation for
reducing risks early and often
6. If you can
reduce certain
software risks,
you can improve
software quality.
In describing the
risks in this
chapter, we use
this template:
An introduction and description
of the software risk
A scenario based on our
experiences
A solution to mitigate the risk
using an aspect of CI
7. CI cannot directly assist with the business challenges
of eliciting requirements from your customer,
understanding the customer’s industry, funding, or
resource management, but by using CI you can
discover problems with the software faster—while
it’s under development
8. Risks
• Lack of deployable software
• Late discovery of defects
• Lack of project visibility
• Low-quality software
9. Lack of Deployable Software
• Integration hell
• The lack of automation increased the overhead of running the build.
Because we were not performing the build in a clean environment on a
separate machine, we had no confidence we were building the software
correctly. The effects of all these were threefold:
• Little or no confidence in whether we could even build the software
• Lengthy integration phases before delivering the software internally
(i.e., test team) or externally (i.e., customer), during which time nothing
else got done
• Inability to produce and reproduce testable builds
10. Scenario: “It Works on My Machine”
• John (Technical Lead): We’re having a problem with the
latest build on the test server.
• Adam (Developer): That’s funny; it was working when I built
it on my machine. Let me see… Yeah, it’s still working.
• John: Oh, I see the problem. You didn’t commit your new
files into the Subversion repository
11. Solution
• Use a separate machine solely for integrating the software
• Create a CI system
• CruiseControl tools Ant, NAnt, or Rake
• build run through tests
• perform inspections
• deploy the software in the development and test environments
12. Scenario: Synching with the Database
• Lauren (Developer): I’m having a lot of problems testing on v1.2.1.b1 of the
database using build 1345.
• Pauline (Database Designer): Oh no, with build 1345, you should use v1.2.1.b2,
but I also need to make a few changes to it first.
• Lauren: I just spent four hours for nothing.
• Pauline: Well, you should have checked with me first.
13. Solution
• Place all database artifacts in your version control
repository
• Rebuild the database and data from your build script
• Test (and inspect) your database
14. Scenario: The Missing Click
• Rachel (Developer): Is the latest build updated to the development server? Where is John?
• Kelly (Developer): Oh, John is at lunch. He’s supposed to have posted the update to the server.
• Rachel: Well, I’ll just wait for John to get back.
Later, John arrives…
• Rachel: John, what happened with the latest build? It looks like the JSPs weren’t precompiled, so
we’re receiving runtime errors now.
• John (Technical Lead): Oops, sorry about that. I must have forgotten to select that option when I
deployed with the Web tool yesterday.
15. Solution
• Automate the deployment process by adding it to the Ant build
scripts that use the application server command-line options.
16. Late Discovery of Defects
The latest changes to the software caused other problems
17. Scenario: Regression Testing
• Sally (Technical Lead): I noticed that the latest version deployed to
the test environment has the same bug that we had two months ago.
Why is that?
• Kyle (Developer): I’m not sure. I tested all of my latest changes.
• Sally: Did you run all of the other tests for the other parts of the
system?
• Kyle: No, I didn’t have time to manually run through those tests.
That’s probably why I didn’t find the bug before we went to test.
18. Solution
The following steps demonstrate how you can use the CI system to enable
automated regression testing on your project.
• Write test code for all of your source code (an xUnit frameworkis a good place to
start).
• Run tests from your build script (Ant or NAnt are the most common).
• Run tests continuously as a part of your CI system so that they are executed at
every checkin to the version control repository (using CruiseControl or a similar CI
server).
19. Scenario: Test Coverage
• Evelyn (Manager): Did you run unit tests before you committed your changes to
the repository?
• Noah (Developer): Yes.
• Evelyn: Great. How’s it going on the other feature you are implementing?
• What didn’t Evelyn ask? Let’s try it again.
• Evelyn: Did you write new tests or update existing tests for your new code?
• Noah: Yes.
• Evelyn: Did all the tests pass? Noah: Yes. Evelyn: How did you determine whether
enough of the code was tested adequately?
20. Solution
• Run a code coverage tool to assess the amount of source code that is actually
executed by the tests
• Using CI can ensure this test coverage is always up to date.
21. Lack of project visibility
Scenario: “Did You Get the Memo?”
There are many different scenarios for this risk; here’s just one.
Evelyn (Manager): What are you working on, Noah?
Noah (Tester): I’m waiting for the latest build to be deployed to QA in order to start
testing.
Evelyn: The latest build was deployed to the test server two days ago. Didn’t you
hear?
Noah: No, I’ve been out of the office the past few days.
22. Solution
• They installed and configured a CruiseControl CI server.
• They added SMS notifications.
• They installed automated agents to check availability of the servers.
23. Scenario: Inability to Visualize Software
• Maile (Developer): Hi. I’m new to the project and I’d like to review the design. Are
there any UML or other diagrams I can see?
• Allie (Developer): Grr. We don’t do the UML here. All you have to do is read the
code. If you can’t read the code, then maybe you don’t belong here.
• Maile: That’s okay; I was just hoping I could see the big picture and determine the
overall architecture rather than slowly interrogating the code. I’m more of a visual
person.
24. Solution
• They began generating diagrams of the design using the CI system.
• They ran an automated code documentation tool, Doxygen.
• They also chose to create a simple one -or two- page architecture document.
25. Low-Quality Software
• Scenario: Coding Standard Adherence
Here is a typical interaction concerning adherence to a coding standard.
Brian (Developer): I’m finding it difficult to read your code. Did you read the 30-page coding
standards document when you started last month?
Lindsay (Developer): I am using the style I used in my previous job. The code I write is kind of
complex so it may be difficult for you to grasp it.
Brian: Writing code that others can’t work with doesn’t make you smarter; it makes you a less
valuable resource. It’s taking me longer to review and update the code. Please review the coding
standards document as soon as you can. First, you can retrofit your existing code, and then get back
to new code using the guidelines.
26. Solution
• Instead of 30-page standards document, they created one.
• They used automated inspection tools as a part of the build scripts initiated by CruiseControl.
• They used Checkstyle and PMD to report.
27. Scenario: Architectural Adherence
• Jenn (Architect): Are you guys following the architecture? I found some problems in
one of the controllers in which one of you is calling a component in the data layer
directly.
Mark and Charlie (Developers): (Perplexed expressions)
• Jenn: The reason I created all of those UML diagrams is so that everyone will follow
the established software architecture. You’re not following the established protocol
that has been in place for months.
• Charlie: I looked at those at the beginning of the project, but the architecture has
changed a few times since then and it’s difficult to keep up.
28. Solution
• Add automated inspection tools to assess adherence to the project's architectural
standards.
• You can use dependency analysis tools such as JDepend6 or NDepend to create
reports for architectural adherence.
29. Scenario: Duplicate Code
• Mary (Developer): Do you know how I can iterate over a collection of User
objects?.
• Adam (Developer): Yes, I wrote some code for that last week. You can find it in the
User package.
• Mary: Great! I will copy it out of there and use it. Thanks.
30. Solution
• Analyze the code using a code duplication analyzer such as Simian or PMD’s CPD. Incorporate this
into your build script.
• Reduce the duplicated code by refactoring9 the code into a single method or component that is
called by the classes where it used to appear.
• Run code duplication inspections continuously by incorporating a code duplication inspector into
your CI system. This gives you the capability to determine code duplication over time.
31. Questions
What risk talk about the problems can cause the latest
changes to the software
Answer: Late Discovery of Defects
What risk contains duplicate code?
Answer: Low-Quality software
What risk contains integration hell?
Answer: Lack of Deployable Software
Que tanto del software hemos implementado?
Respuesta: Compruebe la versión más reciente.
¿Cuánta cobertura de las pruebas tenemos?
Respuesta: Compruebe la versión más reciente.
Que se registraron en el último código?
Respuesta: Compruebe la versión más reciente.
Mediante el uso de CI, se puede construir una “red de seguridad de calidad” y entregar el software más rápido. Cuando se presiona el botón “Integrar” en cada cambio, a construir una base para reducir los riesgos temprano y con frecuencia, como se indica en la Figura 3-1.
Si se puede reducir ciertos riesgos de software, se puede mejorar la calidad del software. En la
descripción de los riesgos en este capítulo, se utiliza esta plantilla:
• Una introducción y descripción de la riesgo de software
• UNA guión basado en nuestras experiencias
• UNA solución para mitigar el riesgo usando un aspecto de C
Por supuesto, no puede CI directamente asistir con el retos de negocio de la obtención de los requisitos de su cliente, la comprensión de la industria, la financiación o la gestión de recursos del cliente, pero mediante el uso de CI se
• Falta de software de despliegue
• Late descubrimiento de defectos
• La falta de visibilidad del proyecto
• software de baja calidad
Usted puede decir, “Oh, he oído hablar de todos estos riesgos antes. Esto no es nada nuevo para mí.”Sin embargo, puede estar consciente de un riesgo, pero no necesariamente mitigarlo. Hay formas más eficientes y productivos para identificar y abordar los riesgos de manera que ya no son un foco en sus proyectos. Como la mayoría de las prácticas, se trata de una aplicación efectiva
En otro proyecto, la construcción de software de integración era un proceso manual iniciada por el IDE. En promedio, estábamos integrando el software manualmente sobre una base semanal. En algunos casos, había ciertos scripts utilizados por el analista de Gestión de la Configuración (CM) para construir el software que no residen en el repositorio de control de versiones. La falta de automatización incrementa la sobrecarga de funcionamiento de la construcción. Debido a que no estábamos realizando la estructura en un ambiente limpio en una máquina separada, que no tenía la confianza de que estábamos construyendo el software correctamente. Los efectos de todos estos eran tres:
• Poca o ninguna confianza en si se podría incluso construir El software
• Fases de integración largos antes de entregar el software interno (es decir, el equipo de prueba) o externamente (es decir, el cliente), durante el cual nada de tiempo se hacían otra cosa
• Incapacidad para producir y reproducir construye comprobable
John (Director técnico): Vamos a tener un problema con la versión más reciente en el servidor de prueba.
Adam (desarrollador): Eso es gracioso; que estaba trabajando cuando construí en mi máquina.
Veamos ... Sí, se sigue trabajando.
Juan: Oh, ya veo el problema. Que no ha cometido sus nuevos archivos en el repositorio de
Subversion.
No podemos exagerar la importancia de eliminar estrecho acoplamiento entre el IDE y sus procesos de construcción. Utilizar una máquina separada exclusivamente para la integración de software. Asegúrese de que todo lo necesario para construir el software que está contenido en el repositorio de control de versiones. Por último, crear un sistema de CI. Utilizar un servidor CI tales como climatizador junto con una construcción automatizado mediante herramientas como Ant, de NAnt, o un rastrillo. Climatizador relojes de los cambios en el repositorio de control de versiones y ejecuta el script de construcción del proyecto cuando se detecta un cambio en el repositorio. Puede aumentar las capacidades de este sistema de CI a incluir tener la carrera de construcción a través de pruebas, realizar inspecciones, y desplegar el software en los entornos de desarrollo y pruebas; De esta manera siempre tiene software de trabajo.
¿Cómo puede el producto se integrará si los equipos no están integrados?
En un escenario de este tipo, el administrador de base de datos, por ejemplo, puede no ser la comisión de la mayor parte de los scripts de base de datos al repositorio de control de versiones. entonces pueden surgir este tipo de riesgos. • El miedo de hacer cambios o refactorización del código base de datos o fuente • Dificultad para poblar la base de datos con diferentes conjuntos de datos de prueba • Dificultad para mantener los entornos de desarrollo y pruebas (por ejemplo, desarrollo, integración, control de calidad y de prueba) Esto afecta negativamente el desarrollo, debido a que la base de datos no está al día con el equipo de desarrollo o viceversa. Los desarrolladores de software y bases de datos pueden estar ejecutando diferentes versiones de la base de datos. Los miembros del proyecto no son capaces de ir a un solo punto de origen (repositorio de código) para obtener la última base de datos. El cuadro de diálogo siguiente ilustra este problema
Esta solución requeriría un cambio fundamental para algunos proyectos; esboza un enfoque en la base de datos no es una entidad separada de desarrollo.
• Coloque todos los objetos de base de datos en su repositorio de control de versiones:
Esto significa que todo lo que necesita para volver a crear el esquema de base de datos y los datos: scripts de creación de base de datos, secuencias de comandos de manipulación de datos, procedimientos almacenados, disparadores, y cualquier otro activo de bases de datos.
• Reconstruir la base de datos y los datos de su Creación de un script,
dejando caer y volver a crear la base de datos y tablas. A continuación, aplicar los procedimientos almacenados y disparadores, y, por último, introduzca los datos de prueba.
• Prueba (e inspeccione) su base de datos:
Por lo general, va a utilizar las pruebas de componentes para probar la base de datos y datos. En algunos casos, tendrá que escribir pruebas bases de datos específicas
La implementación de su software manualmente desperdicia tiempo y esfuerzo. En un proyecto, hemos desplegado manualmente el software según sea necesario mediante la utilidad de administración de Internet del servidor de aplicaciones
En nuestros proyectos, automatizamos el proceso de implementación añadiéndolo a los scripts de construcción Ant que utilizan las opciones de línea de comandos del servidor de aplicaciones. Esto reduce el cuello de botella de esperar a que alguien más para implementar el software y los errores eliminados. Siempre tuvimos una versión contrastable de la última versión de software disponible. Nos encontramos con este script de construcción Ant forma continua desde el servidor IC del climatizador cada vez que se aplicó un cambio en el repositorio de control de versiones. Para obtener más información, véase el Capítulo 8.
En algunos proyectos, se realizó la prueba de forma manual. No sabíamos si los últimos cambios en el software causado otros problemas, por ejemplo, el ciclo infame de la fijación de un defecto sólo para causar otros defectos no relacionados a la superficie. No teníamos confianza para hacer cambios ya que no sabemos los efectos aguas abajo de un cambio. No había manera de asegurar que los desarrolladores se ejecutan las pruebas del software, ya que estas pruebas se realizaban manualmente.
Sally (Director técnico): Me di cuenta de que la última versión desplegado en el entorno de prueba tiene el mismo error que tuvimos hace dos meses. ¿Porqué es eso?
Kyle (desarrollador): No estoy seguro. He probado todos mis últimos cambios.
Sally: Corriste todas las otras pruebas para las otras partes del sistema?
Kyle: No, no tenía tiempo para ejecutar de forma manual a través aquellos pruebas. Probablemente por eso no he encontrado el error antes de ir a probar.
En nuevos proyectos, comenzamos a escribir las pruebas unitarias y componentes en JUnit en el negocio, datos y capas comunes. Para los proyectos existentes, se escribió pruebas unitarias para el código que se ha cambiado, sobre la base de los defectos. Configuramos los
scripts de construcción Ant para ejecutar todas las pruebas unitarias y publicar un informe para cada proyecto
de construcción.
Los pasos siguientes muestran cómo se puede utilizar el sistema de CI para permitir pruebas deregresión automatizadas en su proyecto.
1. código de prueba de escritura para todo el código fuente (un marco xUnit es un buen punto de partida).
2. Las pruebas se ejecutan desde el script de construcción (Ant o de NAnt son los más
comunes).
3. Pruebas de funcionar continuamente como parte de su sistema de CI para que se
ejecutan en cada checkin en el repositorio de control de versiones (con climatizador o un
servidor CI similar).
Y tan simple como eso, usted ha automatizado las pruebas de regresión en su proyecto! Se discute más sobre cómo hacer sus pruebas sean una parte integral de generaciones, en todos los niveles, en el Capítulo 6.
Evelyn (Manager): Corriste pruebas unitarias antes de que cometió sus cambios en el repositorio?
Noah (desarrollador): Sí.
Evelyn: Genial. ¿Cómo te va en la otra característica que esté implementando? Qué no lo hizo Evelyn pedir? Vamos a intentarlo de nuevo.
Evelyn: ¿Escribiste nuevos ensayos o pruebas existentes de actualización para su nuevo código?
Noah: Sí.
Evelyn: ¿Se ha superado todas las pruebas?
Noah: Sí.
Evelyn: ¿Cómo se determina si suficiente del código fue probado de manera adecuada? Ese tipo de preguntas es un poco mejor, pero aún así es un análisis cualitativo de innecesariamente algo que se puede describir más concretamente a través de un análisis cuantitativo. Vamos a la solución
Una vez que los desarrolladores creen o equipos que han escrito las pruebas correspondientes para su código fuente, puede ejecutar una herramienta de cobertura de código para evaluar la cantidad de código fuente que se ejecuta realmente por las pruebas. Muchas de las herramientas mostrará el porcentaje de cobertura por paquete y clase. El uso de CI puede asegurar esta cobertura de la prueba es siempre al día. Por ejemplo, puede ejecutar una herramienta de cobertura de la prueba como parte de escritura de la estructura de su sistema de CI cada vez que hay un cambio en su repositorio de control de versiones. Se discute la cobertura de código en el Capítulo 7