WebCenter Portal an Agile Approach (Continuous Integration) 
Thursday, December 19, 2013 at 07:33PM
David Parry
To recap from my prior post, we have our teams working within their own JDeveloper Applications testing their code locally through the ide built in tools. Alone this can produce “works on my machine” syndrome, so how do we eliminate this syndrome? Through Continuous Integration where we fail fast. I am not going to explain the merits or each nuance to implement CI in this post, I will be showing the project setup and how to get the applications building and running for our Acme Portal Project using Hudson and working with their dependent applications.
A quick explanation of Continuous Integration (CI) it is a software development practice where members of a team integrate their work frequently leading to multiple integrations per day, in a automated build, including running tests to detect integration errors as quickly as possible, verifying each team member’s contribution and integration quickly in a fail fast manner for the entire portal application.
I want to also comment that Hudson Server can be used as a Deployment engine too, not covered in this post but planned for future posts.
Below is the end result of our applications building is a screenshot of our now healthy Portal Project with all the applications (Hudson Projects) building and integrating amongst themselves.

 

 

I want to also comment that Hudson Server can be used as a Deployment engine too, not covered in this post but planned for future posts.
Below is the end result of our applications building is a screenshot of our now healthy Portal Project with all the applications (Hudson Projects) building and integrating amongst themselves.

The above picture is the project dependency tree; I will go into detail on how I have them setup to build and their dependencies. The order in which I describe them is the order that each application is built when starting from scratch and is the path of the dependency tree.  *** Be carful naming ambiguity ***, 1 JDeveloper application maps to 1 Hudson Project and a JDeveloper application can have multiple JDeveloper projects encapsulated, which will just cause more ant tasks in multiple Ant files getting called within the 1 Hudson Project.

1. libs – this project is our repository of third party libraries used in the applications, since JDeverloper and ojdeploy is using Ant I will not involve maven for dependency management. New ADF Oracle has started supplying maven dependencies but this is not the case for WebCenter yet. An example of a third party jar in our project is the commons-lang3-3.1.jar. This configuration says to watch for added jars and if updated, download and then trigger the first lowest application on dependency tree to start to build.

Configuration settings:

2. CommonsProject – this project is triggered when new code is checked in or when a new jar is added to the library project.

Configuration settings:

3. BackendEndProject – this project is triggered when new code is checked in or when the CommonsProject is built.

Conifguration setting:

4. ComponentsProject– this project is triggered when new code is checked in or when the BackendEndProject is built.

Configuration settings:

5. AcmePortal– this project is triggered when new code is checked in or when the ComponentsProject is built.

Configuration settings:

The above configurations ensure that our dependencies are harmonized and that our code will fail fast when they are not, unit testing and Code Quality Metrics are generated for management and team members to review.

The above picture showing a failed build touches on this fail fast paradigm that I have eluded too in this post. This practice when done correctly encourages frequent check-ins to ensure your code is working with others, it also fosters when managed correctly a group think/mentoring when a failure occurs where the team addresses the issues from the broken build. 

 

The above picture is to demonstrate one of the type of reports that can be available to the team and management.  Unit testing and reporting is an important topic and will have its own future post devoted to it.

 

 

 

Article originally appeared on David Parry (http://davidparry.com/).
See website for complete article licensing information.