Hi, all.
We have several product versions to build, each of which may have one or more VS.NET 2003 or 2005 solution files as part of the product. I'm hoping to create a single, turnkey build system using FB5. With this the user will chose the version or label to build, and FB5 will go off and figure out what solutions to build, what order to do them in, and what post-build steps to perform.
I'm thinking that I'll have a master FB5 project that gets the version to build from the user, then reads a custom XML file to get the detailed info against the provided version or label. All solution file(s) and location(s) would be in the XML file as well as any other, version-specific information. The master FB5 project would set the appropriate FB variables, then call out to a 2nd-level FB5 subproject. The 2nd level would call a 3rd-level project for each solution file to build.
Something like that!
Am I going down the right path, or is there a better way? Or am I trying to get blood out of a turnip? Overengineering maybe?
Thanks in advance.
Ross
Ross,
What you describe is certainly possible, and many builds are structured in this way. Having separate projects has advantages (like allowing others to edit them while you’re editing the master for example), but also has disadvantages (it’s not possible to debug through an included project). Another option (which is my personal preference) is to use multiple action lists. They can be more flexible and you can set “Action List Parameters” so they can be called (via Run Action List) with different set of variables depending on external factors. They are easier to debug, and you don’t have to open and close projects while your editing, running, etc.
cheers,
tate.
Ross,
What you describe is exactly how I am designing my build system using FinalBuilder.
I have a script called BuildMaster which does all the building. It reads an INI file which tells it which slave projects to build.
The slave projects contain 2 action lists - “FileSets” and “Build”. The FileSets Action List contains 2 FileSet Define Actions: one for source and one for output. The Build list obviously contains the build steps for the project.
The BuildMaster script iterates through the list of slave projects. For each one, it gets from source all the files listed in the Source FileSet, then runs the Build Action List, then publishes the files listed in the Output FileSet.
I make sure that the FileSets are defined relative to a virtual root, and the root is defined in the INI file, so to build a different branch, I just point this root to the branch (or I can build from the tip).
Since the porducts that my company manufacturers consist of different combinations of components, i create an INI for each product, and then a seperate INI for each version/branch. So to do my nightly builds I simply feed these INIs into the BuildMaster one by one.
I used INI instead of XML because it’s easier to edit by hand, but they have the obvioius limitations as well.
The reason I used slave projects instead of action lists is that you cannot iterate through action lists easily.
What do you mean by not being able to iterate through action lists easily? Do you mean that you store the names of project files in a .ini file (say “Compile.fbp”), then load them up by name…whereas you can’t run action lists by name - you have to point to it at design time?Perhaps there’s a workaround?Steve
Steve,
Yes, the issue I discoverd when first designing my build system is that when executing an action list, you have to specify an actionlist from a drop-down box, so you can’t use an iterator variable. The 2 solutions I came up with for this are:
1) Edit the project file directly to put a variable in this place. I haven’t tested this, so I don’t know if FB GUI will “fix” it on the next project load/save.
2) Instead of using a Run ActionList Action, use an Include Project Action. Point it back to the current project and it will allow you to enter a variable for the ActionList. I can’t remember the reasion why I didn’t use this technique.
Ultimately I like the idea of seperate projects, since each project can then have multiple action lists. In my case, each project has the FileSet and Build lists. The master script defines the FileSets from the FileSets list, then does the SCM get, then runs the Build list. This way the slave projects are comlpetely independant of the source control - if I switched providers for example, I wouldn’t have to change each slave project, only the master script.
Also with seperate projects, it is easier to have multiple developers working on them. If everyone is working from a single master script, then you have to deal with the issue of merging all those changes back together.
Steve,
Yes, the issue I discoverd when first designing my build system is that when executing an action list, you have to specify an actionlist from a drop-down box, so you can't use an iterator variable. The 2 solutions I came up with for this are:
1) Edit the project file directly to put a variable in this place. I haven't tested this, so I don't know if FB GUI will "fix" it on the next project load/save.