“Well it works on my machine” is the single most frustrating developer quote you will hear while working on a portal project. The open source world has experienced great success with automating builds and server deployments using apache maven and continuous integration (CI) servers like hudson, continuum, cruise control and others. Investing time in the beginning of your project to establish and use a build system provides several benefits:
- You get a precise deployment instructions by forcing deployment through scripts. Developers do not get to tweak things outside the process. You do not end up with one lead who does all the magic (and gets sick or goes on vacation like many of us other humans), or a series of differing answers from developers who each use their own methods.
- Deploying through scripts guarantees reliability and traceability for environments below production. The majority of your bugs should be found in these environments so diagnosing bugs becomes easier with tools like recent changes list and SCM commit comments exposed through the web interface of your CI server.
- The reports capability of maven allows leads and architects to catch integration and design issues sooner in the development cycle. (For example, CPD and PMD rules can look for import statements in layers of your architecture where they don’t belong, like importing java.sql.* in your UI layer when data access should be handled in the services layer).
- The continuous integration servers allow the quality assurance team to see where code is moving in real time so that they do not need to question developers about when versions are placed on different environments.
- Developers can check a single project out from SCM without needing a “magic workspace” of related dependencies because maven and the snapshot repository handles the dependencies.
The following series of posts will explain practical examples of maven and portal used at client sites.
Next up: WebSphere Portal and Maven (Part2)