It's all about the answers!

Ask a question

How to do a multiplatform build in parallel

Alexander N (1334) | asked Jan 28 '13, 4:21 a.m.

I have a question regarding build. Assuming I want to build a product on 2 platforms. Are the following assumptions right? 

-I would define a build engine for each build machine (2 in total) and install build agents on those machines
-I would define one build definition containing the required steps to build the product
-I add this build definition as supported build definition to both build engines

My primary question is how I can now trigger a build on both platforms in parallel. Once I request a build I need to choose one build engine or one of them will be chosen automatically, but never do 2 in parallel. The only alternative I see is creating two build definitions and run them independently. But this does also not sound like a feasible solution to me since in this case only the first run build result will contain the built work items if both use the same build workspace.

Any recommendations?

Thanks Alex

Spencer Murata commented Jan 28 '13, 8:15 a.m.

Which build engine are you using with RTC?  Is it the JBE?  What are you building? 

Alexander N commented Jan 28 '13, 10:40 a.m.

 Hi, that would be JBE, right? It is a build of a product containing several subbuilds (Java/C++ and co.) all of them are triggered through a big shell script. So it would be a  Command Line - Jazz Build Engine build definition.

3 answers

permanent link
Spencer Murata (2.3k115970) | answered Jan 30 '13, 8:21 a.m.
 If you are comfortable with Ant, you can use the Ant tasks to fire parallel builds simultaneously.  This would require three build definitions.  The master build definition and then the two platform specific definitions, but then you could build the two platform specific builds simultaneously and contribute the artifacts and logs back to the master build definition.  You could even have it track the status of the two platform specific builds and update the status of the master build accordingly.

permanent link
Tim Mok (6.6k38) | answered Jan 28 '13, 11:47 a.m.
I think it makes sense to use two different build definitions. You would also use different build workspaces for each build definition. It wouldn't make sense to use the same build workspace for multiple build definitions. There would be problems when a build runs then another build starts and wants to make changes to the repository workspace while the first build is loading content. There shouldn't be any issues with work items included since last build. They'll be different build definitions and it compares to the last run of the build definition. Plus, you'll be using different repository workspaces.

Alexander N commented Jan 28 '13, 11:58 a.m.

 Hi, ok I now understand that with two workspaces I would see included work items in both build results because of separated workspaces. I think I am still a bit uncertain about this approach for the following reason. I will also get 2 snapshots of my components, each snapshot representing a specific platform build. I don't think that's a big issue but isn't it safer to have one snapshot that is then built on multiple platforms or  am I wrong here? It is clear to me that I can request the builds in parallel which will also mean their content is expected to be the same. I am also interested if this is then the recommended solution for multiplatform builds or if there are any alternatives and experiences. Thank you so much, Alex

Tim Mok commented Jan 28 '13, 2:46 p.m.

Correct, there would be 2 snapshots because they are separate builds. If you want one snapshot, you'd have to configure your build machine to run the builds for the two platforms. If you're looking to load the same content to two different machines to perform their builds for the platforms, I think you should be able to do that. There might be something in the Jazz Library describing what you want to do or some methods to run builds that you could use.

Alexander N commented Jan 29 '13, 4:49 a.m.

"If you're looking to load the same content to two different machines to perform their builds for the platforms, I think you should be able to do that. There might be something in the Jazz Library describing what you want to do or some methods to run builds that you could use." Could you please elaborate on this 2nd statement. I don't understand it completely. Does it refer to your first statement to use one build machine to trigger the build for two platforms?  

Tim Mok commented Jan 29 '13, 9:53 a.m.

Yes, I mean to use one build machine to trigger the build for your two platforms. I don't know the details of how you want to build your product so maybe the Jazz Library has some ideas of how you can orchestrate your build.

Alexander N commented Jan 30 '13, 3:16 a.m.

 Ok, so that looks like I have more or less to handle the distribution and different build logs and so on by myself if I do not want to have n snapshots and n build definitions for n platforms. To me this sounds still a bit weird since that means I workaround the jazz build. In my perfect world RTC would be able to start one build definition on multiple engines and with one and the same workspace creating one snapshot and using that on all platforms. After that I would be able to see the logs per build engine. If I use the approach you mentioned I would have to do the deployment of the loaded workspace to the other platforms by myself and also the build logs would not be available in a nice build result view. So I see drawbacks with this solution. Any chance to get insights how other "customers" are solving this issue? Thanks

Tim Mok commented Jan 30 '13, 10:34 a.m.

I'm not sure if there's anything quite on the level of what you want to do out of the box. You may have to request an enhancement if you want something more specific. Or maybe this has already been requested. - This might be something similar to what you want.

I think you could look into what Spencer suggested and see what Ant scripts can do for you. Maybe another Jazz developer can comment on how our builds are configured. We have one build that runs and creates packages for various platforms.

showing 5 of 6 show 1 more comments

permanent link
sam detweiler (12.5k6189201) | answered Jan 30 '13, 8:12 a.m.
we have similar issues.. but if you require different platform build tools, then you have to extract the source multiple either case you will have to build the structure manually as you've already discovered.

using different orchestration engines, jenkins or teamcity for example, you could do a cascaded build sequence if the same system is doing a cross compile.. (compiler runs on linux, but creates Solaris executables for example)

the cascaded build would be to extract the stream source, then build from the source, then package results..
I have one of these that does both cross compile of 4 platforms, and standalone compile of 4 platforms, but it runs 5 build definitions.. with 5 separate build records.

currently it uses jenkins as the orchestration engine, with RTC 4.0.1., there is no build triggering yet, so it is either manual start or polling (uck).

maintaining the build workspace such that you don't have to do full source extracts is very hard in this multi-deliverable model

Your answer

Register or to post your answer.