As a Solutions Director for Stelligent Incorporated, Levent helps customers design and implement continuous integration environments, automated build environments and test driven development. His primary responsibilities include the development and implementation of Stelligent's strategic array of software quality products and services. Levent is an IBM and Sun Certified Architect for J2EE and is a published author specializing in software quality and Agile methods.
It’s popular to coin new phrases these days, so here is one from truly yours. The lowest common denominator agility signifies the total agility of an enterprise and it means your enterprise is only as agile as its least agile unit.
Although highly effective agile teams, often supported by maverick managers, have delivered significant results in specific areas of efficiency and flexibility, it remains a fact that a business can be only as agile as the IT systems that support it.
Without looking into enterprise agility, small software teams often fail to impact the overall enterprise agility by concentrating on a narrow deliverable or a small module of the overall enterprise. Current agile literature promotes small teams, which is understandable. A small team is manageable and can deliver real results really quickly. What’s missing is uber-project management with the Enterprise in mind.
Lately, successes in Service-Oriented Architecture (SOA) have enabled business agility by bringing structured approach to model, assemble, deploy and manage key services in the enterprise. It’s probably the “architecture” in SOA which makes some in the industry confuse SOA for technical features or geek-sensation. Some even suggest that it’s nothing but the good old web services repackaged in glossy paper. I disagree. SOA is a largely business term and its designed to enable enterprise agility by making the business decision makers realize what technical folks have been harnessing for years: reuse, transparency, interface decoupling, flexibility.
SOA has the potential to make disperate business units and IT functions work better together; reuse and consolidate software and maintenance and generally make changing services easier and faster and thus it can increase the lowest common denominator agility of your enterprise.
Who cares about software metrics? As a Java developer, I do. Measuring certain aspects of my code lets me quantify my schedule, work effort, product size, project status, and code quality. Oh, and then my project manager cares too. If I don’t measure my current status (number of classes, dependencies to other modules, complexity, code coverage, defects as well as code smells - yes, we all know when we have code smells) and use the data to improve my code and my future work estimates, those estimates will just be guesses. And my project manager expects a little better than guesses.
Metrics is an Eclipse plugin that helps me take a holistic view of various aspects of my code. I use it on a daily basis to see how my project grows and if there are any deviations from the reference architecture. The plugin lets me take a closer look at:
Number of Classes
Method Lines of Code
Number of Methods
Nested Block Depth - Is nice, I like!
Depth of Inheritance Tree - nobody wants to traverse a 16-node deep tree trying to find what they need. 1-5 maybe, but 16….too many levels…
Afferent Coupling, Efferent Coupling - yea, whatever… we saw this here…same story…
Cyclomatic Complexity - If my code is simpler than Paul’s does that make me look “simpler” too?
…and more…
Quick Tutorial
Download and start Eclipse 3.2
Navigate to Help | Software Updates | Find and Install
In the Package Explorer, right-click the solarsystem project and open the Properties dialog. Locate Metrics and check Enable Metrics
Rebuild solarsystem
Navigate to Window | Show View | Metrics | Metrics View
You are looking at a table of various metrics covering the solarsystem project
Feel free to dig down on each metric as it goes from source folder to package to class down to the method
Notice all metrics for this simple project are in blue and there are no exclamation marks in the source code indicating any problems. Let’s change that and make life difficult for ourselves.
Open the preferences page for Metrics and check Enable out-of-range warnings. Drill one level down to Safe Ranges, locate Nested Block Depth and enter 5 as the Max value. Similarly, enter 10 as the Max value for McCabe Cyclomatic Complexity
In a Java Perspective open PlanetUtil.java and add the following method:
public void thisIsAComplexMethod() {
if (true) {
if (false) {
if (true) {
if (false) {
if (true) {
System.out.println("This is a deeply nested if sequence.");
}
} else {
}
}
}
}
if (true) {
if (false) {
if (true) {
if (false) {
if (true) {
System.out.println("This is a deeply nested if sequence.");
}
} else {
}
}
}
}
}
Rebuild solarsystem and return to the Metrics View. You now see two red lines in the results table and an exclamation mark in the code editor. Clearly the new code failed the cyclomatic complexity and nested statements rules of Metrics and therefore was marked red. The cyclomatic complexity of the method is 11, while the if statements nest for 6 levels. Both values are out of the acceptable ranges we defined earlier.
Locate the Dependency Graph View icon in the Metrics View. It can be found on the upper right corner and it is denoted by four dots connected in a square. Click the icon to open the graphical dependency view of Metrics.
The packages in the project are denoted by boxes in different colors. Blue means normal relationship; red means cycles and orange denotes the selected node. There is also a circle in the middle, the tangle center, which displays the number of packages in a particular tangle and the longest walk. In general, the longer the walk the more layers are involved and therefore there may be refactoring opportunities. Similarly, the existence of red nodes and tangles indicates cycles in the package dependencies and that’s also something that may be avoided with a little care. Finally, every node and the tangle center provide right-click menus to drill-down for more details.
The reason for this tangle (cycle) is the JUnit test PlanetUtilTest, which is located in com.solarsystem.jupiter. Let’s do something about this.
In the Package Explorer, locate PlanetUtilTest, right-click and select Refactor | Move. Move the test into a new package com.solarsystem.test.jupiter.
Rebuild the project. Open the Metrics View. Click the graph icon. Everything should be blue. There should be no tangles. No tangle centers. Blue is better than red. Life is good…
What does dependency analysis mean to you? To me it mostly translates to the fact that Common Services (CS) packages should not depend on any of their clients. Does that happen in practice? More than enough to make the case for dependency analysis.
Just like the other tools in this series JDepend can be used in Eclipse or as part of a Continuous Integration cycle. I like to see what’s going on in terms of dependencies and other architectural metrics all the time, so I use both. JDepend calculates:
Total number of classes and interfaces - number of concrete and abstract classes (and interfaces) in the package is an indicator of the extensibility of the package. How many?
Afferent couplings (Ca) - number of other packages that depend upon classes within the package is an indicator of the package’s responsibility. Who depends on me?
Efferent couplings (Ce) - number of other packages that the classes in the package depend upon is an indicator of the package’s independence. Who do I depend on?
Abstractness (A) - the ratio of the number of abstract classes (and interfaces) in the analyzed package to the total number of classes in the analyzed package. The range for this metric is 0 to 1, with A=0 indicating a completely concrete package and A=1 indicating a completely abstract package. How abstract I am? If I change today, how many of my dependents have to change with me?
Instability (I) - the ratio of efferent coupling (Ce) to total coupling (Ce + Ca) such that I = Ce / (Ce + Ca). This metric is an indicator of the package’s resilience to change. The range for this metric is 0 to 1, with I=0 indicating a completely stable package and I=1 indicating a completely instable package. How stable am I? Do I change often?
Distance to Main Sequence (D) - the perpendicular distance of a package from the idealized line A + I = 1. This metric is an indicator of the package’s balance between abstractness and stability. A package squarely on the main sequence is optimally balanced with respect to its abstractness and stability. Ideal packages are either completely abstract and stable (x=0, y=1) or completely concrete and instable (x=1, y=0). The range for this metric is 0 to 1, with D=0 indicating a package that is coincident with the main sequence and D=1 indicating a package that is as far from the main sequence as possible.
Package dependency cycles - dependency cycles are reported along with the hierarchical paths of packages participating in package dependency cycles. If I depend on you and you depend on me, we have to work hard to adapt to each other’s changes, don’t we?
The JDepend4Eclipse plugin is an implementation of the JDepend tool. It follows the same principles and provides visual analysis inside Eclipse. One thing to note is that the plugin works on compiled java bytecode, so its important for your project to build. Related to this is the fact that if you’re following the same package/folder structure for your unit tests as your source code it might be a good idea to compile them into a separate output folder, separate all unit tests into another Eclipse project or just change the unit test package names (by appending the name test for example ), like I show below.
Quick Tutorial
Download and start Eclipse 3.2
Navigate to Help | Software Updates | Find and Install
In the Package Explorer, right-click the source folder src/main/java and select Run JDepend analysis
In the newly opened JDepend perspective click on com.solarsystem.jupiter. Notice how the dependencies, packages with cycles, efferent and afferent dependencies and the metrics views get populated
Notice in the Dependencies view that the com.solarsystem.jupiter package has 3 Concrete Classes (CC), 1 Abstract Class (AC), 4 Afferent Dependencies (Ca) and 7 Efferent Dependencies.(Ce) Also the Abstractness (A) is 0.25 while the Instability (I) is 0.63. Finally, the Distance (D) to the main sequence is 0.11 which is denoted by a green dot in the Metrics view. Also in this view, notice that the package is marked as having a cycle. This is because the unit test PlanetUtilTest resides in the same package. JDepend works on compiled java code and therefore it picks up everything in the target/classes folder, including any unit tests. There is plenty of theory behind the various metrics gathered by JDepend and they are beyond the scope of this quick tutorial. It suffices to say that for any given package the shorter the Distance (D) to the main sequence, the better. In the above case the com.solarsystem.jupiter is used by four other packages, thus Ca=4. The package depends on 7 other packages, including junit.framework, therefore the Ce=7.
Generally speaking cycles between packages indicate complex interdependencies and should be avoided. In this step, let’s eliminate the cycles in the project.
In the Package Explorer locate src/test/java anc right-click on PlanetUtilTest
Select Refactor | Move…
Create a new package com.solarsystem.test.jupiter and click OK
Return back to src/main/java. Right-click and select Run JDepend analysis. All cycles are gone. While we eliminated the cycles, notice also that the distance jumped to 33 from 11 and is now denoted by a black dot.
In Java Browsing perspective select File | New | Interface. Enter a name, IBogus, select the package com.solarsystem.jupiter and click OK. This is just an empty interface.
package com.solarsystem.jupiter;
public interface IBogus {
}
Build the project
In Package Explorer, right-click the source folder src/main/java and select Run JDepend analysis
Notice the Distance is now 16 and the dot turned green. But what did the IBogus interface add to the package? Nothing. It just fooled the tool. This is where special care must be taken. Sometimes emty or unused abstract classes can negatively impact the static analysis and make one belive that the package is in a better state than it actually is. My recommendation is to use other tools that detect unused classes and imports and get the whole system cleaned-up before each dependency analysis.
If you use Eclipse for day to day Java development take a deep breath and relax. You are neither the first nor the only one. In fact, you are part of a growing community of Java developers in the world. SD Times recently reported that two-thirds of the enterprise software developers—66.3 percent—use Eclipse. This adoption rate is a success for an open source project, albeit supported by a giant like IBM.
The agile developers know that at the end it’s often not the tool that makes the difference. It’s the fundamental engineering practices. When the discussion goes beyond the tools it suddenly opens so many possibilities that even the most staunch tools proponents/opponents can sit down and unite in a common strategy. Let’s take coding standards for example. We all know that there are tons of tools for static code analysis and early defect detection. The Agile teams have choices in this matter. They can implement a set of static code analysis as part of their Continuous Integration (CI) cycle and get great reports the instant a potential bug gets checked-in. They can also encourage individual developers to use Eclipse plugins for code analysis and perform the same checks before they commit the code.
Two major plugins for code analysis in Eclipse are PMD and Checkstyle. Of course, Eclipse itself is also catching-up and it is constantly increasing its own set of code style checks. A look at Window | Preferences | Java | Compiler | Errors/Warnings reveals that the number and depth of the built-in code checks is fairly substantial.
Nevertheless, in this blog entry I would like to show you a quick example of how to setup and use Checkstyle for Eclipse .
Despite the fact that I use PMD and Checkstyle (and others for that matter, like Findbugs) in my daily projects, I favor Checkstyle for the following reasons:
The integration of the tool to the environment seems to be tighter
The rule customization and management in Checkstyle is way easier than PMD. I like!
Checkstyle provides a few nifty features such as a pie chart depicting the distribution of problems
Checkstyle comes with a richer set of predefined rules
Better website documentation and easier learning curve
All and all Checkstyle makes my life easier, and especially after configuring a set of rules that make the sense for the project environment, it’s a workhorse! An added benefit of the custom rulesets is that they can be checked into the code repository, shared among the development team and reused in the CI static analysis phase. The latter can be achieved through integrating tools such as CruiseControl, Maven and Ant with the respective Checkstyle plugins. This brings a unified coding standard to the entire development team.
Quick Tutorial
Download and start Eclipse 3.2
Navigate to Help | Software Updates | Find and Install
public class CheckMeUp {
public void thisMethodShouldHaveAShorterAndCoolerName(String WHYALLCAPS, int g) {
if (true) {
}
else {
}
while (true) {
String x = "The white fox jumped over the red rabbit, which in turn jumped over my yellow submarine.";
String y = x + "...";
}
}
}
Build the project
In the Package explorer right-click on checkmeup and select Properties | Checkstyle
Check Checkstyle active for this project and select Sun Checks (Eclipse) - (Global) as the ruleset
Navigate to Window | Show view | Other…
Select Checkstyle | Checkstyle violations
Notice the 27 violations in this simple Java class
Now, let’s play with the rules. Assume that you do not like the Line contains a tab character rule. The sample class has 12 of it. Navigate to Window | Preferences | Checkstyle and Click on New…
Select Internal Configuration, enter a name and description. Click Import… and navigate to ECLIPSE_HOME/plugins/com.atlassw.tools.eclipse.checkstyle_x.x.x and select sun_checks_eclipse.xml. This will import all Sun Eclipse rules for the new custom ruleset. Also note that Checkstyle will create a new custom ruleset xml file under WORKSPACE/.metadata/.plugins/com.atlassw.tools.eclipse.checkstyle/internal_config__xxxxxxxxxxx.xml. This file can be added into the code repository and shared among the development team. Click OK.
Double click the new ruleset. Click Whitespace and uncheck the Tab Character rule
Back in the project properties, select the new custom rule as your configuration
Click OK. The tab warnings are gone.
In the Checkstyle violations view click the chart icon in the upper right corner. This will open the pie chart view shown below
For those who like juggling multiple tasks, Eclipse provides a great opportunity. Take developer testing for example. JUnit comes standard out of the box and the agile developer can literally start practicing Test Driven Development (TDD) right off the bat. As individual developers increase the number and detail of unit tests the team may want to know how much of the code base is actually being tested. This is where test coverage comes into the picture.
The agile teams practicing Continuous Integration gain insight of their test coverage through tools such as CruiseControl and Cobertura. Since test coverage reports are generated as part of the CI cycle, the latter two provide an aggregate view of the test coverage of the entire code base. The reports, while open to the entire team, are mostly analyzed by the architects or project managers who would like to gain insight of the team’s coverage and trends.
Individual developers working with Eclipse can also gain the same insight into their test coverage without having to commit changes and wait for the CI server to complete the build. Coverlipse is an Eclipse plugin designed to measure the test coverage of Java code. It’s fully integrated into the Eclipse environment and allows the agile developer to see which parts of the code are actually tested. The ability to see test coverage immediately provides the shortest path to knowing what each developer’s individual test coverage is, even before a single line of code is committed to the repository.
Quick Tutorial
Download and start Eclipse 3.2
Navigate to Help | Software Updates | Find and Install
public class NumberComparator {
public NumberComparator() {
super();
}
public boolean isGreater(int pFirst, int pSecond) {
if (pFirst > pSecond) {
return true;
}
return false;
}
}
Add the following JUnit test case:
import junit.framework.TestCase;
public class NumberComparatorTest extends TestCase {
public void testIsGreater() {
NumberComparator nComp = new NumberComparator();
assertTrue(nComp.isGreater(5, 4));
}
}
In the Package Explorer, right-click on NumberComparatorTest and select Run As | JUnit w/ Coverlipse
Wait for the test to complete
Open the NumberComparator class. You should see the Coverlipse markers as in the following picture:
Notice the red mark on the left. This indicates that part of the method is not covered by the unit test.
Add a second assert to the JUnit test case as follows:
assertFalse(nComp.isGreater(5, 6));
Rerun JUnit w/ Coverlipse
Notice there are no red marks now as the entire code is covered
Maintainability is an important factor in every software project. The costs of not getting it right run high. In fact, it is estimated that maintainability costs are often 70%-80% of a total project cost.
The main principle of maintainable code is to design loosely-coupled components with small number of connections to other functions. Factors such as solid Object-Oriented Analysis and Design (OOAD) and design patterns impact long term code maintainability.
Diomidis Spinellis [1] lists other important factors that affect maintainability. Among these factors are analyzability, consistency, length of expressions, functions, and methods, locality of dependencies and type checking.
If data abstraction is a policy promoting (among other things) a system’s stability and maintainability, type-checking is the enforcement mechanism. An implementation that takes advantage of a language’s type-checking features will catch erroneous modifications at compile time; an implementation based around loose types or one that circumvents the language’s type system can result in difficult-to-locate runtime errors.
The above statement while valid for stongly-typed languages like Java and C#, is falling short for dynamic languages. The simplicity and the dynamic nature of weakly-typed languages can not only be liberating during initial implementation, but can also have positive impact for long-term maintainability. For example, applications will no longer need big XML configuration files, because changes to the source code will not require recompilation. There are other substantial advantages of weakly typed languages as well [2].
Let’s take an example. In Groovy the entire language is based on weak types. Some argue that strong type checking at compile time helps more bugs to be caught early in the process. I agree with that in general. But the code simplicity that Groovy brings to the table and the whole notion of merging compile-time and run-time can also be seen as an important factor contributing to its long-term maintainability. According to the classical type checking principle, none of the Groovy code can ever be considered maintainable. I think this principle needs to be revisited for the age of weakly-typed scripting languages. What do you think?
Yes. That’s what a colleague was telling me a while ago and today was the day I had to experience it myself.
Despite a later port to .NET, CruiseControl.NET seems to have achieved more in that field than its original home turf, Java.
For example today I needed to tag a repository after a successful build. Well, as of ver. 2.5 CruiseControl does not provide that capability out of the box.
Its .NET brother though seems to have thought about the need to tag an archive after successful builds and therefore comes with this nice tag set:
The <sourcecontrol> tag supports the following attriubutes:
Node
Description
Type
Default
Required
trunkUrl
The url for your repository (eg. svn://svnserver/)
string
N/A
false
workingDirectory
The directory containing the locally checked out workspace.
string
N/A
false
executable
The location of the svn executable
string
“svn.exe”
false
username
The username to use for authentication when connecting to the repository.
string
N/A
false
password
The password to use for authentication when connecting to the repository.
string
N/A
false
autoGetSource
Whether to retrieve the updates from Subversion for a particular build.
bool
false
false
webUrlBuilder
The root url for the WebSVN site
string
N/A
false
tagOnSuccess
Indicates that the repository should be tagged if the build succeeds.
bool
false
false
tagBaseUrl
The base url for tags in your repository.
string
false
false
timeout
Sets the timeout period for the source control operation.
Timeout
10 minutes
false
Of those attributes tagOnSuccess and tagBaseUrl are the two that are needed to tag a source repository after a successful build and unfortunately these along with the entire <sourcecontrol> tag are missing from CruiseControl for Java. Oh well, looks like someone will have to begin exploring command prompt SVN calls to tag the repository.
I’ve been a good boy all year and I listened to my mom most of the time. I sometimes listened to my boss as well. I did my homework and wrote unit tests for all important classes in my application. I was going to write tests for them all, but the neighbor’s boy only did some for the business layer and the girl next door preferred to do the presentation tier only.
I read some nice articles on continuous integration and unit testing including:
Furthermore, as I promised last year, I finally automated my build and went the extra mile and implemented Continuous Integration with CruiseControl. Well, I got a lil help from “Choosing a Continuous Integration Server”, but that’s really not cheating especially since it helped me better understand what it is what it isn’t. While I was fixing my build, I also decided it was time to replace my old Ant scripts with some shiny, brand-new Maven2 scripts. Everything is working OK now, but I sometimes miss the good old Ant and sometimes Maven2’s plugins do not seem to listen to me.
Now, since I’ve been so good and I did everything as promised last year, I want some new and cool toys. First off, I want new plugins for Maven2 for all toys that support Ant, including Macker. Danny was testing it the other day and he said it only plays with Maven 1. I want it in Maven 2 too.
In addition, I want this cool new gadget that will go right into my car’s dashboard and do several good things for me. I do not know that name of this gadget or if it even exists, but you are supposed to know all this, right? So…here is what my toy should do:
Help me scout around – something like Magellan or Garmin, whatever…just need to show me directions so I do not get lost every time I go to see my movie in DC…Oh, and by the way most Navigation devices today come loaded with maps, meaning they are not dynamically updated. My navigation device should use a web service to get the latest and coolest restaurants as well as the places that closed just yesterday.
Read eBooks – driving around in DC can be very time consuming so why not save time by listening to some very cool stories while on the road? I’ve heard some navigation toys are already doing it, so it should be easy…
Play MP3s and support plugging-in other toys such as my iPod, so that I can listen to my beloved Mermaid and the Sheep and Pink Floyd while waiting in traffic…
Connect to the internet and check my emails – many Blackberries, Blueberries, Redberries and other berries are already doing this, but why buy and carry another berry? Can it not be integrated into my advanced nav-toy?
Read my emails while I am driving. I thought this technology was available ten years ago, how come you never brought anything like it to me, ever? Reading emails while driving to work can save so much time. Oh, and also can it send emails be recognizing my voice and sorting out my accent? This would really rock!
While I am connected to the internet, it’d be nice if I can check my CI server to see if everything is still OK. Well…it should be OK, but then again, who knows? I would like to know if some neighbor’s boy broke my build and then also if I can push a button and send a voice mail to that boy or tell his mom that he broke my build?
Check my car for any problems – can it check the oil and book my next oil change? This should be doable…oh, and when that “Check Engine” light comes, can my toy send the factory the code and let them fix it?
Do airline and hotel reservations
Check the weather and do some predictions. Can it combine that with navigation data and show me the least flooded route? Or the least crowded?
Anyway, I do not know how easy will be for you to build this toy, but it’d be really cool if I get it soon. Do not forget the other kids and thank you very much for reading and I am waiting for my presents.
Portability for cars may not mean much, but for software applications it does. An application or system is said to be truly portable when all of its components can run on various platforms, containers, operating systems or even devices with no need for platform-specific compilation. The ideal portable application is also maintained on a single code stream and a platform-independent executable supported by platform-specific configuration files is the only build artifact that end-up in the customer’s hands. Given this definition, a Microsoft .NET application is not portable because it runs only on Windows and potentially only on PCs. A Java application on the other hand, while more portable than .NET is still not the ideal, since it requires a recompile for a handheld device using the J2ME.
So, how does portability affect the overall quality of a software product?
Let’s look at the following scenario.
Initech, is a leading provider of enterprise-grade TPS report cover sheet solutions developed in Java and J2EE. Having Java as the primary build platform has gained Initech a competitive advantage over its competitors due to the fact that the product runs on multiple platforms with no need to recompile.
Noticing that its customers deploy on a variety of J2EE severs, Initech has also invested in an application server-independent solution. By doing so Initech has tapped into a larger market and made its investment worthwhile.
One day Initech’s development group receives a question from an existing customer on whether they can use DB2 as the underlying database for TPS. The customer is in the process of consolidating all of the enterprise databases into a single platform and needs help to transition from Oracle to DB2. This is not an entirely unexpected question and despite that it has been raised several times; the company has kept its products specific to Oracle. And it makes sense to do so. 80% of the application’s business logic resides in Oracle as stored procedures, sequences or objects.
In this example Initech has reached a semi-portable state by creating an application-server agnostic product, but failed to address portability of the database. This failure is ultimately perceived as a product quality issue and as a result Initech is not well positioned to gain or keep non-Oracle customers.
Portability in the age of SOA
With latest advances in Service-Oriented Architectures (SOA), portability has become less of an issue. If proper architectural designs are in place, platform-specific applications can be transformed into less technology-dependent and more accommodating to inter-operable business needs. A good example is two components of a large enterprise application. One of the components is a mortgage processor in .NET and second one is a downstream accounting system in J2EE. Both components access various data stores throughout the enterprise and communicate through asynchronous messages and SOAP-based web services. In this case both components are platform-dependent and still achieve a larger business objective. It may be said that this large enterprise application exhibits high quality regarding portability, because it has achieved internal platform-independence through SOA.
Portability in the age of Open Source
According to a view, building a brand-new enterprise system today has to do more with picking the right open-source frameworks than coding business logic. Knowing that most challenges in software development can be traced to configuration and deployment problems, it is even more difficult to disagree with this view. Today open-source frameworks have come a long way to constitute the backbone of many enterprise applications. When thinking of portability of the enterprise application it is imperative to think of the portability of its parts. Do they work on all platforms? Do they support multiple application servers and/or databases? Will they play well with other open source frameworks?
Monitoring Portability
High quality software is easily recognized with its portability. To ensure high portability, projects should plan properly and monitor builds constantly. Should a problem arise, it should be addresses as soon as possible.
Many leading projects today take advantage of Continuous Integration (CI) and nightly builds to ensure the source code still compiles after the day’s changes. Most projects include some regression testing in the build process, and some projects also generate daily binary builds for public download. Some open source projects such as the Mozilla and Perl use tools such as the Tinderbox tool to help assure portability by building the code on multiple platforms after any code change; if the build breaks on any platform, then all subsequent code changes are limited to fixes [1]. Some projects additionally incorporate platform-specific code style checkers and grid-supported build capability, usually to support testing for portability [2].
Conclusion
To ensure maximum portability across databases, application servers, platforms, operating systems, and devices high-quality software should address portability early and monitor constantly. Leading enterprises make portability part of their Continuos Integration (CI) process and treat portability issues as seriously as broked build issues. Tools such as Ant, Maven and Tinderbox can simplify the continuos portability monitoring.
