It's all about the answers!

Ask a question

Does RTC support creating build files for multiple OS at the same time??


Anish Anil (1811010) | asked Nov 07 '13, 7:18 a.m.
We have CLM 4.0.1 on windows server at our site, and want to do release automation like RPM deployment on multiple servers across cross platforms (like window to Unix ). Is it possible?

We want to deploy our build targets obtained by our build script in the linux RPM format after the build from Windows RTC server to Linux servers. Is it possible to deploy from windows to unix platforms?

If Yes, then How to configure Windows RTC server such that we can achieve this kind of deployment??


Comments
sam detweiler commented Nov 07 '13, 8:27 a.m. | edited Nov 07 '13, 8:35 a.m.

RTC doesn't create binaries.. some build system does that, whether JBE, Jenkins, TeamCity or others.   how you package your deliverable is completely up to you, and how it moves from the build system to the runtime system is also up to you.

I have an app that runs on 6 platforms, both 32 and 64 bit.  my (jenkins) 'build' creates 11 executables which are stored in Artifactory, versioned, etc.
then another build combines those executables with supporting files into the appropriate deliverable packages, also  stored in Artifactory (no binaries in RTC SCM!)...

I am working on the actual delivery step. this is a console app, so I haven't had to install it into a web app server.

I wrote my own ant scripts to manage the build.
I have the 6 build platforms as virtual machines with jenkins agents, and my compiler can do local compile or cross compile to a target platform.  so, when the source changes, 6 builds are started, then a packaging build, then test build.



2 answers



permanent link
Davyd Norris (20221014) | answered Nov 19 '13, 7:11 p.m.
Yes you can absolutely do this.

As mentioned before, if your code requires a specific platform to be built (so for instance iOS builds have to be done on a Mac, z Builds on a zSeries machine, i Builds on an iSeries machine, etc), you will need to install and register a build engine on a suitable machine, but once that is done you can define a build and run it from any connected RTC client.

Similarly, to deploy built components you will need a build engine that can run the appropriate deploy commands on the destination machine. For a z or i deploy, that usually means having a build engine running on the actual machine, but for Unix machines you may be able to use ssh, scp, the Apache or WebSphere console and other remote commands from any build engine with 'line of sight' to the destination machine.

Once you have build and deploy build definitions for each of the types of destinations (and this is a really good thing to have because typically different teams will want to be able to do a test build and deploy to their dev env), you can then create a single master build definition and script that chains the individual builds/deploys together by calling them in the right order to create a cross platform deploy.

To do that last step, you will need to use the Jazz Ant tasks to control the build:
https://jazz.net/help-dev/clm/topic/com.ibm.team.build.doc/topics/r_controlbuildlifecycle.html

permanent link
Robert haig (1.0k16) | answered Nov 19 '13, 4:28 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
 if you are using Build Forge as your build engine, then yes, you can run parallel steps on different platforms at the same time to do whatever you need to.  

For instance, I have buildforge build it's agent on several platforms at the same time.  I make calls to BF agents on AIX, Windows, 2 different linux systems, zlinux, mac, solaris and HPUX.  

You could write steps that did parallel installs on different architectures of systems as well.  You would create the build in and server definitions in BF, and create an RTC build definition pointing at the BF build.

Your answer


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