This page describes how to build a “community-driven” code quality process in an enterprise large enough to have multiple development organizations, development teams, and development initiatives.

• Code review solutions are assembled from parts published to a shared location (e.g. HTTP server).
• Each part keeps track of associated parties, e.g. part owner.
• Zero-install - in order to run a review only the bootstrap jar and component configuration file need to be downloaded to the computer running a review. See Bootstrapping and examples the Sample scenario for more details.
• Guidelines can be automatically checked for compliance. Automated guidelines are called Inspectors.
• Guidelines/inspectors keep track of associated parties (e.g. owners, endorsers).
• Guidelines/inspectors are organized into inspector sets.
• A guideline can also belong to a category.

The picture below shows a sample code review infrastructure.

• Contributor - a person who modifies code review artifacts such configuration files and jar files. Configuration files are edited through Hammurapi Group Configuration Editors Eclipse Plug-ins available on the Update site. Contributors commit modifications to the SVN repository and they become available to users.
• User - runs code reviews, but does not modify code review artifacts in the repository.
• Build server - executes code reviews from a build file. It is an example of a non-human code reviews client.

• Computers participating in the solution are connected using a fast enough network (10 Megabit should be fast enough). Replication or proxying is set up between servers hosting code review artifacts (configuration files and jar files). In other words, downloading code-review related configuration and jar files from a web server or a shared location does not incur prolonged start-up.

This section describes management processes for different types of code review artifacts.

Party is a person or organization with associated attributes, e.g. contact information. Parties are associated with other code review artifacts through a Role relationship. For example, John Smith can be in Owner role for inspector ABC, which means that he maintains it, and in Endorser role for inspector set J2EE Inspectors, which means that he agrees with checks performed by the inspectors in the set, and he uses this inspector set in his organization and development process.

Party model files are created and edited with Party editor Eclipse plug-in. Organization's party model can consist from multiple files referencing each other. Party model files are published to an intranet web server to be referenced by other code review configuration files.

Artifact type is a flavor of Category (see below). Artifact types can be root categories (e.g. Java) or sub-categories, e.g. .Net/C# - C# artifact type is a subcategory for .Net category. Artifact types can reference language modules and inspector sets.

Language modules are libraries to load/parse artifact types in a form convenient for analysis.

Guideline is an inspectors without implementation with runtime attribute set to false. Guidelines/inspectors can be defined in an inspector set or in a standalone file and then be referenced from inspector sets ¹⁾.

The term Inspectors will be used in the text below to refer to both guidelines and inspectors unless the difference is between the two is essential.

Inspectors have associated roles (e.g. Owner), class name, and classpath entries. Inspector/inspector set definition shall be self-sufficient, i.e. it should not require for the client to download any jar files or other resources - all of such resources shall be referenced in the inpsector/inspector set classpath.

See Hammurapi review model for more details about inspector attributes and relationships.

Inspectors/guidelines can be defined proactively or reactively. For example, a guideline can be defines based on a

• Industry best practice or guideline.
• Root cause analysis of a problem.

Inspector and inspector set definitions are created/edited with Hammurapi Review editor plug-in. Inspector implementations are Java classes.

Inspector definition file is published to a web server along with supporting class libraries (jar files).

Inspector sets contain or reference inspector/guideline definitions. Inspector sets also contain category hierarchies. Both inspector sets and categories extend CommonObject from the Party model and as such support party role association.

Inspector set files are published to a web server along with supporting class libraries (jar files). HTML documentation is generated from inspector set definitions with ConfigDoc and is also published to a web server.

Component is the thing which is executed to produce a quality report. Component definitions reference inspector sets. They are created/edited with Hammurapi review editor plug-in and executed either by a command line utility or an Ant task. Generated HTML reports can be published to a web server.

If your organization uses Windows networks, you can benefit from setting SVN to use Windows authentication. It will take password management task off the SVN admin shoulders. There are two ways:

• Use SVN server which supports Window authentication, e.g. VisualSVN Server.
• Use mod_auth_sspi on Apache Http server. Code snippets below show how to set it up with anonymous read-only access.

Modules section in httpd.conf

# Windows authentication
LoadModule sspi_auth_module modules/mod_auth_sspi.so
# Subversion
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

Subversion location definition. You can either paste it into the httpd.conf or keep the definition in a separate file and include it into httpd.conf.

httpd-myrepo.conf

<Location /svn/myrepo>
  DAV svn
  SVNPath D:\SvnRepositories\MyRepo
  AuthzSVNAccessFile D:\SvnRepositories\svn-access.conf
  # try anonymous access first, resort to real
  # authentication if necessary.
  Satisfy Any
  Require valid-user
 
  AuthName "MyRepo Subversion Authentication"
  AuthType SSPI
  SSPIAuth On
  SSPIAuthoritative On
  # set the domain to authorize against
  SSPIDomain MYDOMAIN
  SSPIOmitDomain On      # keep domain name in userid string
  SSPIOfferBasic On      # let non-IE clients authenticate
  SSPIBasicPreferred Off # should basic authentication have higher priority
  SSPIUsernameCase lower
</Location>

Authorization file

svn-access.conf

[/]
*=r
pvlasov=rw

• Configuring Windows Authentication with Apache 2.2.x and Subversion.
• Subversion online documentation.

If you operate in a distributed environment, consider setting up Subversion repository replication.