Planning continuous integration with Jazz SCM
I'm helping a team who wants to migrate to Jazz SCM and practice continuous integration. I would be interested to know if the following configuration make sense or if there are other alternative best practices for doing this.
They would like to have the following configuration: A team collaboration stream to which developers frequently deliver code; a continuous integration server that automatically performs a build + unit tests; and a stable stream which will include snapshots of clean builds for the test team to work against. For the continuous integration server we're thinking to use the jazz build toolkit. We would schedule it to run every few minutes in a build workspace if there are new change sets. Upon success we would like snapshot to be promoted to the stable stream; upon (test) failure, we would like the developers who contributed changes sets into this build to get an email notification. For the notifications piece, we were intially looking at proces/build configuration options in RTC but according to https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=50000 this is not yet supported. We also found the following article http://jazz.net/library/article/195, that explains how this could be done by using ANT + SCM CLI + a file that stores snapshots of green builds which is used to detect the change set contributors, as well as how to do promotion to a stable build. It sounds a bit complex but claims to do the job. Is this the best way to set a continuous integration with Jazz SCM or are we missing anything? Thanks Avi |
2 answers
Hi Avi,
The approach you describe makes sense. For promoting the snapshot to the stable stream, you would use the SCM CLI to deliver the current state of the build workspace into the stable stream. You could specify the stable stream as a workspace property on the build definition. This scenario is quite a bit simpler than the ones describes in that article. All that's required is a command invocation like: <execute command="scm workspace replace-components --all -r ${repositoryAddress} ${targetStream} workspace ${team.scm.workspaceUUID}/> Assuming you've defined the target stream as a workspace property called 'targetStream' in the build definition. The reason for using 'scm workspace replace_components' instead of 'scm deliver' is that you probably want your target stream to end up with exactly what the build workspace has. If you just use deliver, then change sets that have been discarded in the development stream will get punted from the build workspace (since JBE uses replace), but will remain in the target stream (since deliver essentially does a merge). This also avoids the possibility of conflicts. In order to get the SCM CLI to authenticate properly, you need to do an scm login once on the build machine using the same repository address. It's best to do this manually, rather than in the script, to avoid exposing passwords in the build script. For more info from the tool, try: scm help scm help login scm help workspace replace_components Regards, Nick |
|
Regarding email notifications, it's true that #50000 is a work in progress for RTC 3.0. However, there are many existing alternatives for monitoring build status: pop-up notifications, Team Central view, build events in feeds, Builds viewlet in the dashboard web UI...
|
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.