Revision as of 10:08, November 11, 2010

Overview

Rationale

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.

Infrastructure

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

Datei:mavenprotege.png

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 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. Deploy artifacts to test environment and/or other servers
   5. Run unit and UI-Tests
   6. Generate reports
4. The tests are executed optionally on a dedicated test server that runs the TestNG scripts using Selenium and Firefox.
5. 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.
6. Hudson is capable to communicate the results by the means of RSS, Twitter, Mail or Skype, to name a few examples.
7. 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.
8. Optionally Hudson also can deploy directly to a test (manual test) or production server.