Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

How to do a multiplatform build in parallel

 Hi,

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

0 votes

Comments

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

 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
 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.

1 vote


Permanent link
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.

0 votes

Comments

 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

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.

"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?  

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.

 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

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.

https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/239609 - 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
we have similar issues.. but if you require different platform build tools, then you have to extract the source multiple times..in 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

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 6,121
× 562

Question asked: Jan 28 '13, 4:21 a.m.

Question was seen: 6,944 times

Last updated: Jan 30 '13, 10:34 a.m.

Confirmation Cancel Confirm