In the 21st century, the role of programmers in the development of software has changed. No longer should programmers be confined to sitting in dark offices, relegated to being one cog in the long assembly line of work necessary to produce the valuable software that provides businesses with the tools and products that add to the value stream so necessary to fulfill the needs, wants, and desires of product sponsors. In particular, all the members of the software delivery team need to collaboratively contribute to greasing the wheels of software production. Some contribute by defining “Done” for a business process that is being implemented in software. Some contribute by defining “Done” for the user interface that is delivered. Some define “Done” by insuring that the back-end database works with the code at hand. Yet all are interested in “how we are doing” against these criteria as the delivery team works its way through the ordered path of items needed to satisfy these criteria.

In the past, each of the roles mentioned above would have spent their time to serially producing some project artifacts that would be used downstream in the construction process. After software construction, the product would be completely built out and laboriously tested to insure conformance to the acceptance criteria. Anywhere along the way, if issues arose, the resolution of these issues would sometimes result in a complete restart of the process. Modern businesses can no longer tolerate such a slow path to produce the results that they need to gain returns on the investment that they make in producing the software. We now need to insure that projects do not deviate from their goals. We need to validate that today’s fixes do not engender tomorrow’s bugs. We need a parallelized process that engages all the moving parts at once, to bring maximum velocity to this labor-intensive process. That process is Continuous Integration.

In this workshop, we will see how:

• Code check-ins can trigger builds using a continuous integration server
• How builds can check that the code is written right by using unit testing
• How builds can check that the right code is written by using executable requirements
• How builds can check that the code looks right by user interface validation tools
• How to treat your databases like code, by using the same repository as your code to manage schemas and test your databases on the same continuous integration server as your code to insure that there are no mix-ups at deployment time
• How the continuous integration server can monitor the process and alert the right parties when issues arise
• How the same continuous integration server can make deployments instant and easy

The demonstration takes the form of a project built out with a compatible CruiseControl server. The project will then accept changes, show how the modifications are managed, from requirements in Fit/FitNesse, take us though code development, including NUnit and LiquiBase, demonstrate the use of Selenium to insure that the user interface stays correct, and show how the changes triggered by SubVersion check-ins bring the CruiseControl managed integration server to life (with appropriate notifications) where the build occurs and then is checked against the requirements, unit tests, and user interface tests. We’ll also have the integration server check our code 3 ways against the middle and give us some metrics to help keep the quality bar solid and high. And finally, we will see how completely built out packages can then be deployed with automatic schema migrations and appropriate notifications of how the deployments went.