An important aspect of a development model is isolating the construction of shipped objects to a single machine. This is often called a Build Machine. Packaging the application on a single machine allows the environment to be controlled. Changes to the operating system, C++ compiler and LANSA version may all change what is deployed. Thus LANSA recommends that a Build Machine is maintained for each version of the application in the field.
There are two features of Visual LANSA that make this imperative. A version number may now be assigned to a LANSA object and the construction of an MSI produces GUIDs and a version number of the application. The GUIDs in particular are vital for linking together an upgrade of an application to a previous version. If the GUID is different the application is effectively different even though all objects and version information are identical. This is a Windows Installer restriction.
Another extremely useful feature of a build machine is that it can be setup to automatically build your application nightly and then run automated tests on the resulting application.
It's possible to have multiple systems being built on one Build Machine. LANSA recommends against this so that later versions of your application can be built on the latest supported environment - operating system and compiler, and not effect older deployed applications. You will also be able to purchase more powerful machines and be using newer hardware that's more likely to continue running for the life of your deployed application.
A useful method to still use a single machine and ensure against ageing hardware is to use a Virtual Build Machine. The virtual machine is then much more easily moved to new hardware and also allows multiple Build Machines to be running on a single piece of hardware. Given the low level of use of Build Machines this may result in little difference in performance of the build of your application.
Also See
