|
#1
|
|||
|
|||
Best practice for a build environment?
Any tips on good practice for a build environment??
I have just created a Visual Builder script for a system comprising VB, VC++, Delphi components and a Installshield Developer project. We use SourceSafe for version control. At present I am running the Visual Builder script on a development machine. All the script does is get latest source to a clean directory, version stamp, compile and check back in. So it assumes that Visual Studio and Delphi etc are installed on the box. I want to move across to a 'build' machine. Ideally I'd like the build machine to require the absolute bare minimum of software pre-installed. Possibly just Visual Builder, and SourceSafe's command line engine (SS.EXE??). So the script would actually get the VB, VC++, Delphi etc compilers from SourceSafe as part of the build process. Has anyone done this? Is it a sensible approach? Have you any guidelines on what basic set of files I need to store in SourceSafe for each command line compiler? |
#2
|
|||
|
|||
I wouldn't recommend that. You could try it, but there are generally too many other things that get configured during an install of most dev tools than just copying executables. Here are a couple other approaches you could take:
1) Document the steps necessary to turn a fresh system into a build box (identites/locations/versions/SPs of all dev tools to install, etc.). Follow the document when setting up a clean build box. Simplest, but not automated. 2) Create a VisBuildPro project that automates the installation of the dev tools. Your dev tools might support silent install via command-line switches. If not, a tool such as AutoIt [1] or other macro recorders [2] could be called from the build to automate GUI interaction. 3) Use an MSI repackaging tool to monitor your dev tool installs and capture all changes into an MSI that then could be run in silent mode on a clean build box to initialize it. More complicated and expensive, but may be more reliable. [1] http://www.hiddensoft.com/AutoIt/index.html [2] http://appdeploy.com/articles/repack.shtml |
#3
|
|||
|
|||
We run our build machine in a VMware virtual machine from day one. We can move the VM from one piece of physical hardware to another without losing the normal three days of setup time. VMware allows you to save 'snapshots' of your VM along the way, so it is pretty painless to setup.
We've been able to move our build machine from a Celeron-800 to a P4-2GHz in about 10 minutes (the time it takes to install VMware on the new box, plus copy the 2GB VM). VMware runs pretty close to native speed, especially for building source code (where you're not doing much graphics on the screen). Of course, the downside to this approach is that if you ever do need to rebuild the environment from scratch, it is still a manual process. -- Doug |
#4
|
|||
|
|||
Ohter Options
You may do two things to accomplish a new build box environment.
Idea 1 1. Create the base environment - O/S and Apps needed 2. Use Symantec Ghost and create a ghost image - This way you can have a clean environment everytime Idea 2 Use VMware like the previous gentleman was talking about. Just one correction to his statement. You have the ability to produce a Snapshot of your environment and the ability to recreate that environment at a later time if so desired (Non-Persistant) or you can update the snapshot as you go (Undoable) or you can use it as a regular persistant volume much like you do with a non-VM machine. This software gives many options and is pretty fast in doing so compared to Ghost. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|