Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Building a Software Factory

Continuous Builds and Continuous Integration

Continuous integration and continuous builds are mainstay features of modern software factories.
Continuous integration is the practice of development changes being tested, built, and reported in small increments during the development process. Continuous build is an extension of this practice to provide a newly tested build of the software every time a developer commits changes.

Principles of Continuous Integration

Understanding continuous integration principles, in conjunction with continuous build tools, helps drive an efficient software factory, and by extension, efficient software development. These principles include:

  • A unified code repository – the team must have access to shared code (team sharing, SVN)
  • Daily commits – every developer commits daily to the repository so changes are incremental
  • Commits are built – when the code is committed by a developer, the software is built to show it is functional.
  • Builds are automatically tested – When the code is built, unit tests are performed, so if errors are found in a unit test, the developer can correct those errors immediately.
  • Results are available to everyone – if a build breaks, everyone can see where the issue lies and what needs to be done to fix it.
  • Successful builds are deployed immediately (automated deployment) – this ensures that the latest software is available to everyone in the team (product owners, testers)

Developer's Role

With these principles in mind, the developer's role in the continuous integration process can be summarized as follows. Developers should:

  • Commit their code AT LEAST once a day or sooner.
  • Review the results of unit testing, and if unit testing fails on their commit, fix the issue as soon as possible.
  • Update their workspaces before starting each day to get changes from others in the team.
  • Write test scripts for unit testing (unless this is the responsibility of the testing team.)

Software Tools

Software tools can help with managing and practicing continuous integration; in fact, continuous builds are normally vastly software driven. Software considerations include:

  • Repository software - software to manage the code base (SVN)
  • Build software – software to actually build and run unit testing (ANT)
  • Communication software – how to communicate information among the team members.
  • Deployment software – in our case, Servoy Application Server.
  • Continuous build software – software to manage the continuous build process and make sure each step is occurring.

CruiseControl

There are many different choices for continuous build software available, such as Continuum, Bamboo, and others. The continuous build software chosen here is CruiseControl, as it is open source, has a no-cost license, and is well suited for Java applications.

Overview

CruiseControl is a free continuous build software package released as open source software. It is managed by ThoughtWorks, whose employees created the original version. It is well suited for Java based projects, and some of the more notable features include:

  • Plugins for builders such as Ant, NAnt, Maven, and Xcode; source control such as CVS and SVN; and notification via email and instant messaging.
  • Other 3rd part extensions for various report and usability.
  • Open source so extensible and customizable.
  • Web application

Installing CruiseControl

NOTE: These instructions are for a Windows installation.
CruiseControl can be downloaded at the following location: http://sourceforge.net/projects/cruisecontrol/files/. At this location, there are three options available:

  • Binary version that can be copied into a file location.
  • Source code version that can be compiled with specific feature sets.
  • Windows installer that will install a Windows service with the installation.

These instructions will concentrate on using the Windows installer. The other two options are available if a more customized installation is desired or necessary.
Once the installation file has been downloaded, executing the installer should open a window

Select all the components. Next, the installer will ask for a location. This location should have sufficient rights for read/write

Clicking install will start the installation. After the installation is complete, there should be a folder containing the program contents

Also, if you open the Local Services control panel for the machine, there should be a service named "CruiseControl Service" available that has not been started yet. Go ahead and start the service to start CruiseControl.
CruiseControl ships with a default Java project named ConnectFour. When CruiseControl starts, it will try to build this project (using Ant) and return a result. To see if this has occurred, open the CruiseControl dashboard at the following location: http://<serveraddress_or_localhost>:8080/dashboard|||||\. The application dashboard will launch and you should see a screen like below

If the build has passed, then CruiseControl is configured and running properly in its default state.
Some troubleshooting tips if installation does not work:

  • If you cannot launch the dashboard, make sure Servoy is not running (see configuration tips below)
  • If the dashboard is running, but there are build errors, as indicated in the builds tab, one issue could be that your Java environment is not properly configured. The connectfour project depends on Ant being configured correctly, and if there are issues with the program reaching Ant, or if there are multiple versions on your machine, there might be issues with the build. Check your Java environment and environment variables to ensure that Ant runs properly.
  • Make sure the service actually starts. If not, check to make sure the install actually completed and that you have proper permissions in the installation location.

Configuration Tips

As CruiseControl and Servoy are both Java driven applications, they share some Java technologies, and by default, share port configurations as well. If you plan to run CruiseControl and Servoy Application Server on the same machine, port changes will need to be made one application or the other in order for the applications to work properly.
NOTE: only one or the other needs to be modified, not both.
Changing ports for a Servoy Application Server installation is detail here (ADD LINK).
To change port configurations for CruiseControl instead, modify the wrapper.conf file found in the CruiseControl main folder. See the section below

  1. Application parameters. Add parameters as needed starting from 1
    wrapper.app.parameter.1=CruiseControlWithJetty
    wrapper.app.parameter.2=-webport
    wrapper.app.parameter.3=8080
    wrapper.app.parameter.4=-jmxport
    wrapper.app.parameter.5=8000
    wrapper.app.parameter.6=-configfile
    wrapper.app.parameter.7=config.xml
    wrapper.app.parameter.8=-rmiport
    wrapper.app.parameter.9=1099
    Note that parameter 3 and parameter 9 are conflicts with Servoy Application Server default ports. Change these ports to any other available port on the machine.

    Using CruiseControl with Servoy

    In regards to Servoy projects, CruiseControl is used to fill the following needs in our software factory
  • Checking the SVN for new versions of the software, or building the software when the SVN is committed.
  • Running the unit tests against the project.
  • Providing a new build of the software for testing and availability.

CruiseControl is very flexible in how it can be configured and the methods and strategies can differ depending on a variety of factors. Rather than explain everything that can be done with CruiseControl and a Servoy project, it is more beneficial to provide an example of CruiseControl and the supporting applications configured for a continuous build server.
The Building the Servoy Software Factory section will cover in detail setting up a continuous build server for a Servoy project.

Updating a Servoy Application Automatically

Once we have a proper .servoy file and it has passed unit testing (via our continuous build software), we would like to take it one step further and make the build available to the team for testing and use. This section talks about how to setup a Servoy Application Server to automatically import solutions.

Servoy Application Server Solution Import

At this time, there is no built in functionality to import .servoy files, nor is there any API available in the maintenance plug in for this functionality. It is possible to post to an application server and import a solution in that manner. An example solution for this has been provided at ServoyForge.
The importer solution will use the post the export file to the application server as if it were a web service. The solution import occurs, and the solution becomes available to the clients of that web server immediately. The import is triggered by changes to a .servoy file; when the file is changed via the build server process, an import occurs.
To use this solution, it is placed on an application server as ran as a batch processor. It takes one argument, the path and name of the file to import. A batch processor is started for each file to watch for changes.
<Screenshot here>
The solution is open source and configurable, so if you need to make changes in how it operates to meet your needs, just open it in Servoy Developer and make any necessary changes.

Building the Servoy Software Factory

This section is a guide to setting up a Servoy software factory.

Continuous Build Server

The following information is a step by step guide to building a continuous build server. It includes a sample configuration for a sample set of solutions, as well as instructions on where to change this information for your solutions.

Step 1 – Create a folder

Create a folder for the software factory:
c:/SoftwareFactory

Step 2 – Install CruiseControl and Edit wrapper.conf

Install CruiseControl into the c:/SoftwareFactory/CruiseControl folder. Instructions
This is also a good time to make configuration changes to the wrapper.conf file Instructions <<LINK>> To work in this environment, we need to change and add some lines to wrapper.conf for the run directory and classpath:
Add two lines right above the wrapper.java.classpath lines in the wrapper.conf

wrapper.working.dir=c:/SoftwareFactory/workArea
set.CC_INSTALL=c:/SoftwareFactory/CruiseControl

Modify three lines as follows:

wrapper.java.classpath.1=%CC_INSTALL%/lib/wrapper/*.jar
wrapper.java.classpath.2=%CC_INSTALL%/lib/*.jar
wrapper.java.library.path.1=%CC_INSTALL%/lib/wrapper

"NOTE"

To avoid a bug that makes the dashboard not show build status, use Java 6 instead of 7; modify the following line to point to Java 6:

wrapper.java.command=c:/Program Files/Java/jre6/bin/java

Save the wrapper.conf file.

Step 3 - Download and Install SVNAnt

SVNAnt is a helper application used by ANT to update projects from the SVN. Download the application from: http://subclipse.tigris.org/files/documents/906/49042/svnant-1.3.1.zip. Extract the contents of the zip file into c:/SoftwareFactory/svnant-1.3.1

Step 4 – Install Servoy Developer

We need an installation of Servoy Developer. Install Servoy Developer with the following options set

  • Install Servoy in the folder c:/SoftwareFactory/Servoy
  • Install with a separate PostgreSQL database, create a repository connection and create the repository.
  • Create the workspace as c:/SoftwareFactory/DeveloperWorkspace

Step 5 – Install command line SVN client

SVNAnt works better with a command line client. Recommended: slikSVN

Step 6 – Checkout Solution Into Work Area

Using the command line client installed, check out the solution (or solutions) from the SVN into the workspace file located at c:/SoftwareFactory/checkout/testrunner. For details on how to do this, please refer to the SVN client you have chosen.

Alternate steps if the SVN does not contain the solution

If your SVN does not contain the solution yet, and you have the solution in a .servoy file, do the following:

  1. Open Servoy Developer.
  2. Install Subclipse 1.8 if you have not done so already and restart.
  3. Import the solutions into the current workspace (should be c:/SoftwareFactory/DeveloperWorkspace)
  4. Share the solution with the SVN.
  5. Close Servoy Developer
Using Servoy Developer to Checkout Solution

As an alternative, you can use Servoy Developer to check out the solution. (NOTE: you will still need the command line client for operation of the software factory)

  1. Make sure the solution is in the SVN repository.
  2. Open Servoy Developer, verify Subclipse 1.8 is installed.
  3. Change workspace to c:/SoftwareFactory/checkout/testrunner.
  4. Checkout the solution(s) from SVN repository.
  5. Change the workspace back to c:/SoftwareFactory/DeveloperWorkspace
  6. Close Servoy Developer.

NOTE: If you are using a SSL repository, the SVN server certificate must be trusted. Otherwise, the software factory will fail.

Step 7 - Configuration

A few items need to be configured at this point.
cruisecontrol.properties – a few items in this file need to be configured for your environment

  • Mail properties – so CruiseControl can send emails on build status
  • SVN properties – username, password
  • Directories – workArea, and others.

config.xml - configure the modification sets
these lines need to be configured for every solution in the workspace
<svn localworkingcopy="${svnDir}/solution1" property="solution1_changed" />

  • No labels