Apparently, creating an automated daily build procedure was sufficiently challenging in the past that many developers didn’t find the effort worth their time. I would dispute that assessment, but at present it’s a non-issue anyway, since Delphi 2007 makes it ridiculously easy.
Twice within the past week, I have responded to a question in the Delphi newsgroups by suggesting that the questioner fix their stated problem with a small tweak to their automated build procedure. The questions were:
- How can I make sure that my developers always remember to check their code into source control before doing a build and giving the executable to someone?
- How can I add a version resource to my executable corresponding to the Subversion revision identifier, and keep it in sync with all successive builds, without having to remember to set the version resource value manually?
And twice the questioner has responded that they do not have an automated build procedure. So twice, I have further suggested that they devise an automated build procedure, thereby fixing not only their stated problem, but probably several others as well. And twice, the help-seeker has expressed hesitation about adopting such a comprehensive fix to their problem.
Given that automated daily builds are almost universally held to be a best practice of software development, why the resistance?
Perhaps because in the past, creating an automated build procedure has been difficult — relative to choosing Build from the menu, anyway. At the very least, you had to figure out the the command line compiler syntax, and probably fiddle with the resource compiler as well. You might create a batch file which would quickly grow as you added features to your build, or buy and learn a specialized tool for just this purpose, like FinalBuilder.
With Delphi 2007, however, laziness is no excuse. The steps to do a command line compile are as follows:
- Choose the RAD Studio Command Prompt item from the Start menu.
- Change to the directory your project is in.
- Type
msbuild YourProjectName.dproj
That’s it. No futzing with command-line switches unless you actually want to configure something. Make it a scheduled task, and you have a daily build. The next step is to make the build handle the source control checkout automatically. You can do this with a batch file, or within msbuild action. But that’s step two. The important thing is to create a daily build procedure that you can "build upon."
{ 15 } Comments
Any chance you’d like to pony up your solution to #2 as a blog post as well? I recently updated our automated build with a WANT script that does this but it’s a little hackish and I’d love to see some other ideas out there.
Semi-related, one thing that I dislike is the difficulty in rebuilding or maintaining my build environment. A typical project uses 3 to 9 components and it’s not easy to just commit a new version of something like the DevExpress components, I have to remote into the build machine and re-run the setup. Not so automated.
I’d love to see someone do a blog post on maintaining components and their various versions in relation to the projects that use them.
Shawn, regarding setting the resource value, msbuild will do this for you with this cheap tool. Alternately, edit/create an RC file and include that in your project with the
{$R foo.RC}compiler directive.That said, you asked for my solution so such things, which is to use FInalBuilder. But that tool, although a bargain for what it does for us, is pricey and complicated enough that it could be viewed as a barrier to doing an automated build in the first place, and the point of this post is that there is no excuse to not do it anymore.
I’d love to do a post on the ideal way of versioning components in a build, if only I knew what it was. I know lots of non-ideal ways, including:
Version component source and rebuild all components from source
Install all versions separately and version the library path (or the -r switch in the IDE) to load the appropriate configuration for the build.
Use virtual machines for each configuration
All of these have (different) significant downsides.
> I’d love to see someone do a blog post on
> maintaining components and their various
> versions in relation to the projects that use them.
I second that thought. I just have three machines - two developers and one build machine. Keeping third party components in sync is the biggest headache I have with the automated build. I have actually gone to adding the source for simple components in my project and just creating them in code instead of dropping them on a form.
One other thought: One thing we do is use a unit test to check component versions against what we define to be appropriate for the application version. The unit test is versioned, since it’s just source code. So if we do somehow misconfigure the build machine, the unit test fails.
Thomas, the documentation for the feature I describe is in the help system.
Our semi-useful way of doing components is using svn’s externals property inside of each project, so we end up with:
\project1
\src
\components (via externals)
Problem is this only works for simple components and not the big boys like Raize, DevExpress or RemObjects and only for automated build machines.
I’ve echoed for years and even during the latest round of betas that there needs to be a unified component packager that ships with Delphi to create component installers. If all components were packaged the same there would be a consistant installation method which could then in turn be scripted and versioned.
It is almost trivial now to use CruiseControl.net to do your daily builds, it took me all of 1 hour to get it to work. I wouldn’t even fiddle around with want scripts or anything like that anymore.
Regarding versioning of components: I have made a simple component installer to easily install/uninstall any component or component pack. I’ve developped this for my current dayjob because we’re upgrading to delphi 2007. To help everyone get all the components installed quickly, I wrote a simple installer/uninstaller.
It uses an XML file to specify which path to add to Delphi’s library path and/or browsing path, and which BPLs to register.
I’ve even integrated the "big boys" like Raize Componets 3 and 4 and DevExpress 3 and 4. I still need to add DevExpress 6 though.
I’ve built all packages and added BPLs and DCUs to subversion along with the source code. The BPLs en DCUs are registered with Delphi (so everyone uses the same version) and the source is registered in the Browsing Path.
Now I still need to figure out how to link all our different projects with the correct version of all these components. I can’t really use svn:externals on each project, because the components directory is about 600Mb (With DevExpress, Raize, JEDI, it adds up quite fast)
I’m also using CruiseControl.net, it took some time to get it configured for use with Delphi 5 and 7. But we are now using Delphi 2007 and the configuration was like 1 minute. I like the MS Build task in CC.net, made building an application so easy.
I’m also creating my own version update tool. It also allows you to synchronize your build version with the cruisecontrol label.
Robin
Craig,
I did one one better. I added the correct values to powershell for Delphi. The advantage of using powershell over and above the standard dos box is significant
Joe
msbuild was not found when typed at the command prompt. I also didn’t have an option for "RAD Studio Command Prompt" - which if I did all would be good. If you have this same problem then you can just run rsvars.bat found in the bin directory, the full path being: C:\Program Files\CodeGear\RAD Studio\5.0\bin
Then msbuild should run fine. The batch file just adjusts the PATH environment variable.
Alister
Automated builds are a must and certainly are not that hard to set up. I’m using NANT and Subversion and have a build script that compiles all required resources, exes, dlls, then creates 3 installation packages and version dates them. I’ve been meaning to plug cruise control into the build process, but have not yet. One of the best advantages is consistency of the deliverables.
As far as components versioning goes, I use a DCC32.cfg file to define the paths to the components a particular project requires. Every project can have different versions of components if required. My build machine only has the command line compiler and any required library files. I’ve also implemented builds in Virtual Machines which has the benefit of preserving an environment that may be hard to reproduce several years down the road.
>Type msbuild YourProjectName.dproj
This wont work on the build machine unless the two machine have identical settings of the IDE. But we can create an .msbuild file for the build machine and it imports the project file .dproj. The problem of this tech is there is not many docs tell you how to overwrite the settings of .dproj to suit the build machine such as paths. We can also specified paths in the .cfg file, but we don’t know the priorities of settings in these three files.
Bo Chen Lin: Two words: "Source control."
{ 1 } Trackback
[...] will be useful to developers and teams who have a functioning continuous integration process (and you should) and want to impose standards on this sort of code which can be checked in to the repository. But [...]
Post a Comment