Jazz Build Strategies
Our project has the following configuration
1 Integration Stream
4 Components
Each of the components is a different technology and requires a difference build methodology, therefore we have a build engine for each technology and a build definition for each. Each build has its own repository workspace and each repository workspace has all 4 components present. This is all working fine, with each build running continuously however I have made a couple of observations.
1 Integration Stream
4 Components
Each of the components is a different technology and requires a difference build methodology, therefore we have a build engine for each technology and a build definition for each. Each build has its own repository workspace and each repository workspace has all 4 components present. This is all working fine, with each build running continuously however I have made a couple of observations.
-
Every time a change set is delivered to a component, all four builds start even though the change set only modified one component. Ideally we only want to build a component if it has changed. Is there a way to prevent this?
-
This results in each build generating its own baseline and snapshot which is named after the build. This is confusing as the Java build baseline is being applied to the database code.
- The snapshots and baselines are only visible in the build workspaces. Do I have to deliver them back to the integration stream once the build is finished?
-
Is it possible to associate multiple builds with a release?
Is this setup correct or should I seek to move to a single build engine that builds all the components? This could be tricky as the build platform is different for each component. Also is it possible to detect which components have changed in the build script (we are using command line builds)?
Any help or guidance would be appreciated.
Thanks
Accepted answer
If you want to have a single stream, you could have each build workspace only contain the component that is to be built. Once the build workspace has just 1 component in it. Go to the Flow target section in the Stream editor. Select the Stream flow target and choose to edit. You will want to choose the option to only flow chosen components (the component you want to build). If you do this, then only the changes in that component will trigger the build. Also the snapshot that gets created will only have that component (& baseline) in it.
As for delivering the baselines back to the stream, its up to you. The baseline is just capturing the configuration that was built so that you can revert back to it, rebuild it, compare other baselines against it to know differences. It doesn't need to be delivered back to the stream.
As for delivering the baselines back to the stream, its up to you. The baseline is just capturing the configuration that was built so that you can revert back to it, rebuild it, compare other baselines against it to know differences. It doesn't need to be delivered back to the stream.
One other answer
I would split the integration stream up into individual streams for each of the components. I will assume that the components don't depend on each other if they have different technologies, so you could have a single component per stream. But even if that is not the case you could include the other components in each stream and just not allow deliveries to the supporting components (the components that are not the focus of the stream.) Then either have component owners/stakeholders deliver the streams up to integration after a successful build, or use the post build deliver option on the build definition to automatically deliver after the successful CI build. Then the snapshots will be associated to the stream that is linked to a specific component and everything should make more sense logically.
~Spencer