Continuous Integration
I’ve recently read a couple of great books on the agile discipline of continuous integration. For those not familiar, this is the concept of using automation to build source code on a very frequent interval, and report defects or failures in the build to the team. The initial movement began after JUnit started getting popular, and people realized, that if their unit tests could be run each time a check in occurred, they would be able to detect defects much master. As such, the book Continuous Integration: Improving Software Quality and Reducing Risk became a big influence in how I build quality into the development process from the very beginning. Part of doing good work with this is using JUnit (or other unit testing framework). JUnit has since been ‘borrowed’ into NUnit for .NET and zUnit for IBM mainframe COBOL. However, it is not a magic bullet. It does require diligence and meeting an understandable level of code coverage in order to get the reporting of unit test results meaningful. Also, the process of integrating multiple code artifacts at the same time can provide valuable insight into the quality of the application as well. If the code does not compile , even though the unit tests pass, you’ve met yet another defect early in the development cycle. The cost of correcting a defect goes up almost exponentially with each phase of development. Thus correcting a defect early in the development cycles saves money over the long haul. This. book is great in showing you concrete examples of how integration can save time and money.
Continuous Delivery
My interest continuous delivery comes from using the Jazz Build Engine (part of Rational Team Concert) and ANT scripts to automate the process of building software. When a developer checks in code to our RTC project, build engine will then check out the source code, compile it, test it (with JUnit), package the source, and optionally deploy to an integration test server. Having this automated saves hundreds of man hours and ensures that it is done exactly right every time. It also allows us to catch defects immediately when it happens. Integration however, sometimes requires you to deploy it in order to catch any issues that may arise. The book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automationgoes over several scenarios where just testing and compiling is not enough. Actually deploying an application can involve multiple steps, all of which might be time intensive and manual. Eliminating these manual steps saves time. Also the build script itself further helps to document how the deployment process should work. If you’ve ever heard of the concept of DevOps, this is really the heart of it. I highly recommend the book if you’re just getting started with automation. It is certainly an eye opener. If you are new to this blog, we’ve discussed several similar topic on RTC and the Jazz build engine in prior posts that you might find helpful.
Related posts:
Creating ANT Files from and existing Eclipse project
Deploying to WAS or Tomcat using the RTC build engine
Monitoring the status of builds in RTC
Other related links:
http://continuousdelivery.com/
http://www.slideshare.net/jmcgarr/continuous-delivery-8341276
http://www.infoq.com/articles/Continous-Delivery-Patterns
http://www-01.ibm.com/software/rational/devops//solutions/continuous-release-deployment
