Metawerx Java Hosting Small Logo

Ideal Build Box - Forum Page

This page is the central planning document for the new Build Farm.

After initial feedback, and using CruiseControl internally, I am adding a list of things that I need myself for a box suitable of building the metawerx utils libraries and sites.

Your continued feedback is wanted, and required for a good service, so please comment on and/or edit this page before and during the trial.

When editing, use your first name before any points to make them easier to identify for everyone. There is no need to add any additional identification unless you want to.

Table of Contents

Subversion

Repository Size

  • (Neale) minimum 200mb, I think 1gb would be really good, it allows enough growth plus SVN can be used to store other non-code documents for central distributed access
  • (Neale) metawerx is currently using 530mb for a series of project repositories, and other centralised documents

Repository Access

  • (Neale) SVN must be available over HTTPS, for encryption and ease of use through firewalls. HTTPS also reports transfer rates and total transfer, which helps to guage usage and total time for large commits/updates by eye
  • (Neale) FTP access to the SVN repository folder is useful, because it allows offline backup or install of the repository.
  • (Neale) Ability to modify users file is very useful too, and allows full access control for the repository as teams grow/change

CruiseControl - Shared or Dedicated?

Initial Idea

  • (Neale) Plan options could be Single Project in Shared CruiseControl instance, or Multiple Projects in Dedicated CruiseControl instance.

Single vs. Multiple Projects

  • (Neale) Most customers use multiple projects. The problem is that to list multiple projects in the same CruiseControl "reporting" website, means that all projects in CruiseControl are visible. This is no good for multiple customers. Therefore, to allow multiple projects, it would be necessary to have a dedicated Cruise Control instance. This would involve a memory limit of course. I have found that 32mb is sufficient for small projects, but 64mb is better.

Config.xml

  • (Neale) Using a stock config.xml, or metawerx-operated config.xml is pretty useless. Customers need to be able to edit config.xml to change publishing to email and artifacts folders. The other stuff stays pretty static, but it would have been very annoying if I couldn't edit the SVN bootstrapper, or SVN modificationset properties while setting the project up. I imagine everyone has customised config.xml quite a bit.
  • (Neale) For a single project shared instance, a config properties file can be linked in from the main config.xml.

Logs

  • (Neale) It is really important to have access to the cruisecontrol.log file, to make sure builds are happening, and adjust timing. This would only be possible in a dedicated instance though.

Current Metawerx Decision

  • (Neale) Multiple projects in a dedicated cruisecontrol instance would be useful. Single projects in a shared instance would be annoying. We are probably going to only offer a multi-dedicated option. However, pricing needs to be cheap enough to make this worthwhile to our customers.

General Service Concepts

File System Layout

  • (Neale) Customers would have FTP access to their CruiseControl base folder, allowing config.xml access and cruisecontrol.log download
  • (Neale) CruiseControl binaries and ANT 1.6.5, 1.7.0, would be available in a read-only shared area, removing them from the user's disk-space usage. The config.xml would be able to select 1.6.5 or 1.7.0. Extensions such as SVNANT would be requested, and approved by metawerx, then made available for customer use.
  • (Neale) Metawerx would restart CruiseControl daily in order to roll-over the log file so that it doesn't grow too large. 3-4 revisions would be kept available for customer review.
  • (Neale) The webapps folder would be part of the CruiseControl folder, allowing the customer to edit the web.xml for the reporting system, as well as some other exciting ideas such as a staging server (see below).

Security

  • (Neale) CruiseControl would be run as a separate user per customer, preventing access to other areas of the file system such as other customer's cruisecontrol folders, but allowing the use of ant, java and other standard features, like a standard metawerx dedicated JVM

Monitoring

  • (Neale) Metawerx would monitor each CruiseControl instance, and automatically restart it like our Tomcat VMs and dedicated JVMs

New Setups - What would the default setup look like?

  • (Neale) a blank SVN repository, locked with rw access by a single user (users file direct access available)
  • (Neale) a basic CruiseControl setup that builds the ConnectFour sample, with an email publishing sample included (config.xml access available)
  • (Neale) a subdomain for the reporting website / staging site, locked with username/password access to prevent external access (possibly with access to users config file available)
  • (Neale) wiki-based help pages showing examples for adding SVN integration
  • (Neale) customer should set up a similar environment locally for local testing and to get used to the build cycle, they can copy the metawerx setup to get started
  • (Neale) customer should be able to immediately start modifying the ConnectFour project, or load up their own projects, however ConnectFour will not be added to the SVN repository by default, because then it just has to be deleted later by the customer

The Build/Test Cycle - Additional Ideas

Types of Testing

  • (Neale) JUnit for unit testing is great, but with something like a website, there are other important functional test areas. For metawerx, these are as follows. (Feel free to add more if there's something I haven't covered).
    • (1) database (load test data, test units or functionality, unload test data)
    • (2) external services such as email
    • (3) website functional post-deployment testing (web.xml, context.xml, JSP/website workflows)
    • (4) broken link testing (will this site have 404 errors if deployed)
    • (5) test class code-coverage testing (do my tests cover all my code, what percentage is untested?)
    • (6) custom tags, servlets, JSP

(Neale) Email can easily be handled by setting up an email address for testing purposes. This could be sent email, and email can be retrieved by POP3 in test-classes to check it arrived etc...

Staging Server Idea (partially covers 3 and 4, still need linktest software and functional test software)

  • (Neale) Since we will be running Tomcat on the box anyway, to provide the reporting front-end, I am thinking of allowing a full webapps folder within the environment, per customer, so that the build scripts can deploy a site which can be used for functional testing as part of the build cycle.
  • (Neale) This could be set up by the customer so that it erases after each test, or erases before each test and stays live after the build as a staging server. Various releases or build types could be deployed in this way inside the webapps folder.
  • (Neale) This would allow developers to connect to the deployed staging-site, to assist development.
  • (Neale) The staging server could not be used for commercial purposes, and would always have a metawerx subdomain name. During builds, access would be slowed down. The purpose would be primarily for the reasons listed above. Real websites would be deployed to the metawerx hosting services on the production servers.
  • (Neale) The cruisecontrol reports application would be the ROOT application by default. This could be renamed by the customer in order to allow the deployed project to be the ROOT application.

Staging Database Idea (covers 1)

  • (Neale) A database would be provided as part of the service, one of PostGreSQL, MySQL or FireBird or SQL Server 2005
  • (Neale) This would be used for loading of test data as part of the build cycle, and it's usage patterns would be similar to the Staging Server above.

Investigating Quilt (to cover 5)

  • Quilt looks good, but is no longer maintained. Still investigating. Coverage-testing isn't so important, but it would be nice.

Investigating EMMA (to cover 5)

  • EMMA works really well. I've written an article in the articles section about how to use it with CruiseControl. We have deployed this on a large customer project and our own projects with excellent results, and not terribly difficult to integrate.

Apache Cactus (to cover 6)

  • Cactus can test Custom Tag Libraries, JSP pages, Filters and Servlets. I was able to get it working in the current build environment using it's embedded Jetty instance, with just a few changes to the build file.

(Neale) Maven would be good too and will be available on the build farm. I am investigating some functional-testing frameworks for web-applications, and also code-coverage testing to test the effectiveness of tests. If you know of any good ones, please comment on this page.

--NealeRudd, 23-Jan-2007


(Neale) Also investigating some software called Quilt, which checks how effective your tests are by monitoring coverage during a test run. More info soon. Looks to be no longer supported, so not sure if it works yet. Anyone know of anything newer?
* Added above

--NealeRudd, 23-Jan-2007


(Neale) Apache Cactus is a nice tool as well. It can test Custom Tag Libraries, JSP pages, and Servlets. I can get it working in the current build environment using it's embedded Jetty instance. I would be interested to know what everyone thinks about having a range of servlet containers available on the build server to run tests against multiple containers.
* Added above

--NealeRudd, 24-Jan-2007

navigation
metawerx specific
search
Share
tools
help

referring pages
...nobody

Share