Difference between revisions of "Stanford:OverviewPage"

From Protege Wiki
Jump to: navigation, search
Line 6: Line 6:
 
# 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.
 
# 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.
 
# After development code including test code is checked in to a version control system as SVN.
 
# After development code including test code is checked in to a version control system as SVN.
# This or a schedulderr trigger a build on the integration server. We chose Hudson for continuous integration. On this server the usual steps are described in a Maven script:  
+
# 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:  
 
## Retrieve code (including test code)
 
## Retrieve code (including test code)
 
## Retrieve libraries
 
## Retrieve libraries
 
## Compile code (including test code)
 
## Compile code (including test code)
## Run Unit-Tests
+
## Run Unit-Tests via TestNG
 
## Deploy artifacts to test environment and/or other servers
 
## Deploy artifacts to test environment and/or other servers
## Run UI- and System-Tests
+
## Run UI- and System-Tests on test enviroment via TestNG and Selenium
 
## Generate reports
 
## Generate reports
 
# The war file is deployed to Tomcat (optional step)
 
# The war file is deployed to Tomcat (optional step)

Revision as of 02:12, November 12, 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 tests are executed via TestNG scripts using Selenium and Firefox. (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.