This is so simple that I’ll just start this post with the 3 easy steps. Then I’ll throw in some screenshots for good measure.
1. Setup a single build stream and a different workspace for each of the targeted platforms
2. Before running a build, re-parent the build stream to the code stream to be built
3. Update the workspaces and kickoff the build on each platform.
Simple, eh?
Now let’s drill down a bit with what this looks like in the StreamBrowser. Let’s say we want to build different versions of AccuRev across 4 different platforms (Linux, MAX, Unix, Windows).
I have created a build stream with a workspace for each of those platforms (Step 1). The physical location of the workspace is located on the approriate build server. In addition, the private workspace contains any platform specific configuration files necessary for the build.
In this example, I am performing a build from the Accurev_INT stream. Something you might want to do in a continuous integration environment. As changes are promoted by the developers, the build automatically kicks off on each platform.
Now let’s say I decide to do a build for the Accurev 4.5.3 release for all platforms. With a single command, I will re-parent the build stream to the AccuRev_4.5.3 snapshot (Step 2).
accurev chstream -s Build -p Accurev_4.5.3
>
After performing an update on the workspace and I can now run my build scripts (Step 3) and just like that, we’ve performed builds on all the platforms.
Can you make use of this technique in your organization?
I like it. Is there a sensible way to handle environment specific files that are sprinkled throughout the tree and intermingled in the same folders with files that are promoted? We have this situation between qa, stage and prod.
Thanks – Mike
Without digging deeper into your specific environment, one method comes to mind on how you can create platform specific files for your builds that use the same filename so you don’t have to create additional complex logic in your build scripts.
Element links allow you to create “aliases” to your files. Elements are like symlinks, except they 100% managed in AccuRev. An element link can be created to point to whatever platform you are compiling on.
For example, let’s say you have 3 config files named config.win, config.unix, config.mac in the config directory. You can then create an element link called config.ini that would point to the .win in the windows stream, .unix in the unix stream, and .mac in the mac stream.
This allows you to manage all the config files in one place and then use pointers in the applicable streams.
Again, not sure this is how your environment is setup, but I’d be happy to drill down further with you.
Regards,
Rob
That actually solves the problem for me in a far less complicated way than I had been considering. For one thing it would allow me to still promote the files. Thanks – Mike