Navigation:  Commands and Procedures >

Automated Builds

Previous pageReturn to chapter overviewNext page

Visual Build provides several options for automating builds.

 

1.Integration with the Windows Scheduled Tasks / Task Scheduler service is provided for quickly setting up scheduled builds.
2.Support for continuous builds is available by using a repeating build rule.
3.The GUI App provides a command-line interface.  The graphical Windows application is launched to open and build the project.
4.A Console App also provides a command-line interface (with nearly identical syntax), which can be used to perform a build without displaying a user interface or requiring interactive desktop access.
5.A project can be launched on a remote server by using the Remote tabs of the VisBuildPro Project or Run Program actions.  Also see the Server.bld sample for more details.
6.Remote builds can also be initiated via a web interface.  See the WebLauncher sample.
7.The application and builder objects are exposed as COM automation servers, so you can write script or code in any language that supports COM to automate a build.

 

Note: You can use the VisBuildPro Project action to launch the GUI App or Console App from within a build.

 

Each method actually uses the COM server components behind the scenes, so the build behavior will be the same regardless of the method used.  All components honor the settings configured in Application options.  The only difference is that the GUI App may prompt for input (for instance, if an undefined macro is encountered or upon exit if the project has been modified), the Console App never prompts for input and any changes made to the project will be discarded unless explicitly saved in the build, and code that utilizes the COM objects will need to provide their own prompting if required.

 

The ability to save the build status with the project can be useful during automated builds.  By adding a Run Script steps which saves the build status with the project on failure, if the automated build is launched again on that project, it will continue from the point of failure.  It is also advised to add a step which saves the project without the build status on a successful build so that the next time the build is launched, the entire build will be performed (otherwise, all steps would be marked completed and no steps would be built).  Also, ensure that the project file is writeable before saving, or the save step will fail.  See the SaveStatus.bld sample for an example of using this capability.