As Nick says, there is some fairly terse documentation on the wiki.

As to your questions:

Get code (via a "load"), build, add changes to a changeset, deliver the changeset, create a baseline and then deliver that.

Is that the "correct" way to be doing this?

That sounds good. One gotcha I can think of is in the "get the code" step. If the workspace you're loading/committing/baselining is used by other users or other builds, it's possible you'll have some build pollution.

Similarly, make sure you handle personal builds properly. If a user is running a personal build, they probably don't want a baseline delivered to the dev stream along with a bunch of compiled artifacts. See the wiki topic for an Ant script that prevents delivery on personal builds.

Also, is there a way prevent people making changes during the build process? If someone else commits a change while it is building, the baseline isn't going to represent the built code.

When you say "making changes during the build process", I assume you're talking about the stream. If that's the case, then you have nothing to worry about. The baseline generated on the workspace is independent of the stream state. ie, if someone adds a change-set to the stream while the build is running, the baseline won't include that change, even when delivered to the stream.

In 2.0, it is possible to lock items in a stream, thereby preventing the delivery of change-sets modifying those items, but that is probably beyond your requirements.

e

Hi Duncan,

Are you using the RTC build system at all, e.g. to kick off your build scripts?

If so, you can configure the build definition to have a Jazz SCM configuration, where it builds from a dedicated build workspace. The build workspace is typically configured to have the team's stream as a flow target. When a build request is processed, it checks if there are any changes to accept from the stream. If so, it accepts them, optionally creates a snapshot (one baseline per component), loads the workspace onto the build machine, then runs the specified build script, which typically builds stuff and uploads artifacts and logs back to the build result on the Jazz server. If there were no changes to accept, it simply deletes the build request as not needed.

Even if you don't use the Jazz SCM configuration in a build definition, and prefer to drive it directly from the SCM command line, you could still follow the same approach of having a dedicated build workspace. This approach would provide the isolation you're looking for, since the build process is the only one modifying the build workspace.

For some other use cases using the SCM CLI for builds, have a look at:
https://jazz.net/wiki/bin/view/Main/SCMUsingTheCliInBuilds