Why switch to automated project building

An automatic process is one of the basic components of Continuous Integration, a software development technique that consists of frequently integrating (several times a day) the work of the various developers involved in order to find integration issues as soon as possible. The developers’ work environments are integrated through the commit operations they make to a central repository, and the integration is checked by an automated project build process which may also include other tests.

But whether in the context of Continuous Integration or of less frequent integrations, automating the build process of what's stored in the repository has advantages of its own.

Building a system is usually a complex process that involves multiple stages, from obtaining the latest changes made to the repository, generating and compiling everything necessary, executing reorganizations, and finally moving the programs to the deployment environment, to name just the most visible ones.

Add the ins and outs of building multiple versions of a project (which take elements from different places, need components from different versions, leave the results somewhere else, etc.) and several build variations (with or without tests, building certain modules or leaving them out, generating a setup file or not, etc.), and the complexity involved can grow significantly.



Automating this process implies, among other things:
 

• Avoiding the need for a person dedicated to executing each stage, checking the results, deciding the next step to take, etc.
• Not depending on the knowledge of a single person to perform these steps correctly and in adequate order. What happens when this person gets sick or takes a holiday?
• Avoiding the risk of mistakes made by this person, something that often happens in the most stressful situations; that is to say, when there is more risk of potential damage.

In addition, the possibility of running the entire build process in a completely unattended manner and with a single command gives us the chance to take the next big step, which is to automate the process triggering itself. For example, we may want to have the repository checked for new commits on a regular basis and, if so, to have the project automatically built. Some projects may need this several times a day, while others only at night or even during weekends. Here is where the so called continuous integration servers come into play. One example of such servers is CruiseControl.NET.

Combining GeneXus Server and CruiseControl.NET

A continuous integration server is a service that monitors a certain software repository to find out if changes have been made, and in this case it may trigger a project build process.

In our case, we will use CruiseControl.NET as continuous integration server. This software will monitor –at intervals set by us– knowledge bases managed by a GeneXus Server. If new commits are found, it will update a copy of the KB and run the build process. Both the update and build processes will be run through MSBuild tasks with no need to start GeneXus to do it.
 

In the Community Wiki you will find step-by-step instructions to set up this automation process with GXserver.