Build best practices for large systems
I have a question about build best practices working with large teams of developers and large amounts of source artifacts (gigbytes). Those systems commonly have large build scripts that each developer runs when they begin working on a change. And they reexecute the build script (or part of it) after making changes. Note this is a different process than simply letting Eclipse builders do all the work as we make changes.
A while back (may have even been the beta), the client had a build engine built into it we could launch and I believe it executed the build against the local sandbox. Now it looks like all builds execute on a server. So we pay the (potentially huge) cost of transferring all the source artifacts to a remote machine for each build. That process makes sense for team builds but not developer (aka personal) builds since our repo workspace already exists on the local machine.
One option is for each developer to run the build server locally and point it to their RTC sandbox. But we would have a build engine for every developer - doable, but not too elegant. Another solution is to run the build script outside of RTC, but that script is embedded w/ RTC-specific commands to interact with the repository. And another solution have scripts that separate the RTC commands from the system build commands so we can run the build locally outside the RTC client and not interact with the repository.
Am I missing something? Have any others bumped into this problem?
Many thanks.
A while back (may have even been the beta), the client had a build engine built into it we could launch and I believe it executed the build against the local sandbox. Now it looks like all builds execute on a server. So we pay the (potentially huge) cost of transferring all the source artifacts to a remote machine for each build. That process makes sense for team builds but not developer (aka personal) builds since our repo workspace already exists on the local machine.
One option is for each developer to run the build server locally and point it to their RTC sandbox. But we would have a build engine for every developer - doable, but not too elegant. Another solution is to run the build script outside of RTC, but that script is embedded w/ RTC-specific commands to interact with the repository. And another solution have scripts that separate the RTC commands from the system build commands so we can run the build locally outside the RTC client and not interact with the repository.
Am I missing something? Have any others bumped into this problem?
Many thanks.
One answer
To my knowledge, the RTC build system never (in beta or otherwise) did a
build in the local sandbox. It has always queued up the build for
processing by some build engine. One reason is that the user wouldn't
be able to use that workspace/sandbox while the build was going on. You
don't pay a huge cost (except for the very first build) if you tell the
build not to delete all files before starting a new build ... in that
case, only the changed files will be loaded onto the build machine, and
it will be just as fast as incrementally loading files into the
developer's sandbox.
Cheers,
Geoff
harryk wrote:
build in the local sandbox. It has always queued up the build for
processing by some build engine. One reason is that the user wouldn't
be able to use that workspace/sandbox while the build was going on. You
don't pay a huge cost (except for the very first build) if you tell the
build not to delete all files before starting a new build ... in that
case, only the changed files will be loaded onto the build machine, and
it will be just as fast as incrementally loading files into the
developer's sandbox.
Cheers,
Geoff
harryk wrote:
I have a question about build best practices working with large teams
of developers and large amounts of source artifacts (gigbytes).
Those systems commonly have large build scripts that each developer
runs when they begin working on a change. And they reexecute the
build script (or part of it) after making changes. Note this is a
different process than simply letting Eclipse builders do all the
work as we make changes.
A while back (may have even been the beta), the client had a build
engine built into it we could launch and I believe it executed the
build against the local sandbox. Now it looks like all builds
execute on a server. So we pay the (potentially huge) cost of
transferring all the source artifacts to a remote machine for each
build. That process makes sense for team builds but not developer
(aka personal) builds since our repo workspace already exists on the
local machine.
One option is for each developer to run the build server locally and
point it to their RTC sandbox. But we would have a build engine for
every developer - doable, but not too elegant. Another solution is
to run the build script outside of RTC, but that script is embedded
w/ RTC-specific commands to interact with the repository. And
another solution have scripts that separate the RTC commands from the
system build commands so we can run the build locally outside the RTC
client and not interact with the repository.
Am I missing something? Have any others bumped into this problem?
Many thanks.