Latest revision as of 11:47, December 16, 2010

Overview

Infrastructure

Infrastructure with all servers and information flow

The workflow is supposed to work as follows (the numbers refer to the numbers in figure XY):

1. The developer works on his machine where he/she writes code and tests. He works with the usual set of tools as Eclipse and GWT as well as Selenium, JUnit respectively TestNG for testing.
2. After development code including test code is checked in to a version control system as SVN.
3. This or a schedulder triggers a build on the integration server. We chose Hudson for continuous integration. On this server the usual steps are described in a Maven script:
   1. Retrieve code (including test code)
   2. Retrieve libraries
   3. Compile code (including test code)
   4. Run Unit-Tests via TestNG
   5. Deploy artifacts to test environment and/or other servers
   6. Run UI- and System-Tests on test enviroment via TestNG and Selenium
   7. Generate reports
4. The war file is deployed to Tomcat (optional step)
5. The UI- and System-Tests are executed via TestNG scripts using Selenium. (optional step)
6. The reporting (e.g. error reports, compile errors, code and architecture metrics) which is triggered by Hudson is done via Sonar which also performs an analysis of code and architecture.
7. Hudson is capable to communicate the results by the means of RSS, Twitter, Mail or Skype, to name a few examples.
8. Both, the developer as well as the build server (Hudson) retrieve the Maven script as well as the libraries from a central repository server. We chose Nexus.
9. Hudson deploys tested artifacts to repository from where developers and users can download it

Rationale

ISO 9126: Quality criteria of software

The rationale for continuous integration and testing is as import as evident:

• Avoid redundant tasks as
  • Build software (including compile, package etc.)
  • Run unit tests
  • Run system tests including UI-tests
  • Evaluate quality of code and architecture
• Provide a faster start for new programmers. A one-click install is the ultimate goal. Any unnecessary step will take time, might lead to errors and has the potential to frustrate “newbies”.
• Bugs which are found early are easy and fast to fix. As longer it takes and as more commits were done as more difficult and tedious the bug fixing will become.
• (Web-) Protégé is supposed to attract continuously more programmers. At the same time, the quality of the software has to be assured. Especially with respect to maintainability and functionality. But also quality aspects like efficiency and reliability can be partially tested automatically.

Description and Rationale for Tools

This page is intended to give an overview on the systems and to describe why we selected particularily this set. How to install, operate, and use this tools is described in

• administrator guide
• developer guide

Hudson

Hudson is a server application to automatically and continuously build, test and deploy one or more projects. It provides an overview on the build and tests results including code metrics, architecture metrics, JUnit results and much more.

It is obvious that such repetitive tasks should be automated. However, there are several products to facilitate this task. Among those there is CruiseControl We decided to prefer Hudson over CruiseControl for the following reasons:

• Installation is simpler. It is just download the jar file. E.g. no installation of DB necessary.
• Administration is simpler: An easy to use web interface gives access to all administrative settings
• Easy integration with other tools e.g. with Sonar, TestNG and communication services
• Related to Plug-ins
• Easier plug-in development
• More plug-ins available (e.g. twitter, email, Sonar, Selenium)
• Easier plug-ins administration

Hudson executes the Maven script(s) including builds as well as unit and UI tests, triggers reporting and communication of build and test results.

<Link>Instruction how to install and configure Hudson.

Nexus

Nexus the central and shared repository for all developers (and users)

As more libraries a project requires and as more dependencies these libraries have as more complex the setup of a new development environment and of executing a build become. For example WebProtégé has dependencies to Protégé, to the Google Web Toolkit, to Apache libraries, and so on. And even the referenced libraries are interdependent.

Maven is capable of resolving these dependencies. Nexus is a repository manager which allows you to centrally provide these libraries in a versioned and reproducible manner. Nexus also can serve as proxy. So the developers (and the build system) just need to retrieve these files from the repository instead of individually downloading these artifacts redundantly. This not only saves bandwidth, but also reduces the load on “Central” (the central Maven repository).

Nexus is not replacing Maven. Nexus proxies the Maven requests to a central Maven repository. Nexus provides as the feature not only to proxy repositories, but to operate our “own” repository which is the deployment target of all of our projects. Please note that Maven itself uses a repository (the Maven repository).

Further feature of Nexus include

• a quick and easy search of all artifacts.
• Developers don’t have to have the entire source. They just can work with libraries from Nexus. This makes collaboration easier.
• Clear responsibility and maintenance of “official” 3rd party libraries.

An additional list of reasons for using repository managers can be found at http://www.sonatype.com/books/nexus-book/reference/sect-repoman-reasons.html.

A comparison of repository managers (Apache Archiva, Artifactory, and Nexus) can be found at http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix.

“Standard” developers not necessarily have to deal with Nexus. She just uses Nexus as a repository to retrieve artifacts from. If she requires a new jar-file, this has to be done as described in the How-Tos. However, we recommend to have a local repository as well.

<Link>Instruction how to install and configure Nexus.

Sonar

Sonar is a very powerful platform to report the quality of software products considering aspects as

• Code metrics as complexity
• Error/bug patterns
• Architectural metrics
• Conformity with coding guidelines
• Results of tests (Unit tests, UI tests) including errors, failures and code coverage.

Sonar provides both, a comprehensive overview on the quality o projects as well as the option to drill down to single metrics/aspects and even to the single line of source code.

Sonar serves as shell compiling and consistently visualizing the results of numerous tools as Checkstyle, FindBugs, PMD, and TestNG .

<Link>Instruction how to install and configure Maven.

TestNG

We prefer TestNG over JUnit for the following reasons:

• Better separation of test code and test data
• Better grouping of tests and re-use of test groups
• Better support for parallel (multi-threaded) testing
• TestNG automatically produces test reports without having the need to use other tasks as JUnitReport.

Maven

Maven is used by

• Developers to initially create his workspace (initial build)
• To define the build and test process which is executed and scheduled by Hudson.

<Link>Instruction how to install and configure Maven.

1. validate
2. generate-sources
3. process-sources
4. generate-resources
5. process-resources
6. compile
7. process-classes
8. generate-test-sources
9. process-test-sources
10. generate-test-resources
11. process-test-resources
12. test-compile
13. test
14. prepare-package (maven 2.1+)
15. package
16. pre-integration-test
17. integration-test
18. post-integration-test
19. verify
20. install
21. deploy

Firefox

We prefer Firefox over other browsers for two major reasons:

• Firefox is available on LINUX, too. LINUX will be our server OS.
• There is a Selenium Plugin available for Firefox.

Having said this, it is nevertheless worth mentioning that the web applications have to be tested on other browsers as well. This requires no plugin. The plugin is only required for automated UI tests.

Selenium Server (Selenium Remote Control)

Selenium Server Architecure. Picture taken form http://seleniumhq.org/projects/remote-control

Selenium remote control is a server which allows developers test web applications (even with AJAX) using Java code (e.g. JUnit, TestNG) or any other language.

Selenium RC automatically launches the browser, simulates the user actions and kills the browser afterwards. Thereby Selenium RC facilitates the complete test automation ($rarr; regression testing) of rich web applications.

<Link>Instruction how to install and configure Selenium.

Selenium Plugin (optional)

The Selenium IDE is an optional Firefox plugin which helps developers to record actions in the browser and generate Java code. However, the capture & replay functionality is very limited. Therefore Selenium tests will be written as regular Java respectively TestNG code.