Visitors to this site

Continuous Integration @local

Including Automated Tests and Automated Builds are some of the key aspects in a Continuous Integration development activity. Most of us are already familiar with these premises but, in the other hand, it is a common practice to commit/push our updates once all Unit Tests run successfully; leaving those Integration Tests and, why not, inter-dependencies troubles to be analyzed after the remote repo build. Anne Thomas Manes estimates that ongoing maintenance could achieve 92% of the total lifetime cost of an application.

Automated builds, with the use of any Integration Tool such as Hudson/Jenkins, are commonly performed “over there”, after our commits, but why don’t prevent to those possible dependency issues? or those failed integration tests?

Martin Fowler explains in his Continuous Integration article: “The point of testing is to flush out, under controlled conditions, any problem that the system will have in production. A significant part of this is the environment within which the production system will run. If you test in a different environment, every difference results in a risk that what happens under test won’t happen in production…” . Decreasing the gap between the Local dev environment and the Production environment reduces the chances of a Red Ball nightmare.

Continuing with my last post, eBayOpenSource with Sonatype Nexus, I decided to complete my dev environment with the use of Hudson+Sonar+Nexus tools. Here are the simple steps: