Baseline, Snapshot and Build Process
Hi
I've read lots of posts regarding snapshot in this forum. So here is my conclusion: 1. Snapshot is close to ClearCase composite baseline. 2. Snapshot can be promoted (to somewhere, not levels), but can't be delivered. Here are different processes to do an incremental build (assume we have a build repository workspace created off a development stream has multiple components): Old ClearCase way: ~~~~~~~~~~~~~ 1. In the development stream, create a new baseline for all components if required. (Is this step necessary? It's not in ClearCase, since creating a new baseline in a stream will automatically create new baselines on each component if necessary.) 2. In the development stream, create a new snapshot to record the above baseline set. 3. Accept the above snapshot into the build workspace. How to do this? 4. Run the build, if successful, rename the snapshot to a standard name, e.g. "Nightly Build Pass". If failed, delete the snapshot. 5. Developer accept the above snapshot into their workspace. How? New RTC way? ~~~~~~~~~ 1. Accept all new changes from the development stream into the build workspace. 2. Run the build. If successful, 3. In the build workspace, create a new baseline in all components, using a standard naming convention. (if 3 do this?) 4. In the build workspace, create a snapshot to record all the above new baselines. I am not sure about the next step, in order for developers to "rebase" to the latest build pass code base. Shall I 5. If I promote the snapshot to the stream, how can developers can "rebase/accept" these new baselines created in the build workspace, not delivered to the stream? 6. Or I deliver all these new baselines/snapshot created in 3 to the stream, so the developers can "rebase" to? Things bothering me are: 1. When I create a new snapshot, it only create new baselines in changed components, not in components have no changes. 2. Changes are showing in Pending Changes in the unit of Change Set, or baseline, not in snapshot. 3. I wish I can still work at the snapshot level, deliver a new snapshot from build workspace, and then developer rebase/accept it, as a whole. Thanks Jirong |
8 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Oct 20 '11, 2:18 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
If you are flowing changes to developers, or flowing changes to the
build, then you should do so by delivering those changes to a stream, not by creating snapshots. The developers (or the build) will then just accept changes from that stream. The purpose of a snapshot is to record a point in history, so you can "jump to it" (for example, to reproduce an old configuration), and not as a mechanism for flowing changes. Cheers, Geoff On 10/20/2011 12:08 PM, hujirong wrote: Hi |
If you are flowing changes to developers, or flowing changes to the Following this concept, 1. We should always create a new baseline in each component after a successful build, e.g. mark them as "BUILD_LATEST", despite the component has new change or not. This way, the developer can clearly see each component in his workspace is with the latest build. 2. We don't need to create a snapshot during an incremental build. 3. Snapshot can be used to create a new release or something like that. Thanks Jirong |
You may want to look at the post build deliver feature that was added in 3.0.1.
https://jazz.net/library/article/126 (the anchor to the question is broken so search for "How do I automatically deliver changes to a stream after a green build?") You can deliver the changes from a build to a stream. Working off that stream will be working off the latest successful build. Users can also create a workspace from a snapshot. Snapshots should be created with every build. 1. When I create a new snapshot, it only create new baselines in changed components, not in components have no changes.I don't see a reason to create another baseline when there are no new changes. The baseline that is already there describes everything for the snapshot. 2. Changes are showing in Pending Changes in the unit of Change Set, or baseline, not in snapshot.How do you want this to be shown? Are you suggesting an indicator that you are in sync with a snapshot? |
1. When I create a new snapshot, it only create new baselines in changed components, not in components have no changes.I don't see a reason to create another baseline when there are no new changes. The baseline that is already there describes everything for the snapshot. 2. Changes are showing in Pending Changes in the unit of Change Set, or baseline, not in snapshot.How do you want this to be shown? Are you suggesting an indicator that you are in sync with a snapshot? 1. If I create e.g. a new baseline called "BUILD_LATEST" on each component for each successful build, then developer accept it, then the developer can see all his components in his workspace are with "BUILD_LATEST". It's just easy for them to make sure they are with the latest build. Otherwise how would they know they are sych with the latest build? 2. In a multiple components stream/workspace, how can a developer know if his workspace is based on the latest successful build? All he see are incoming change sets and baselines. How does he know if he needs to accept a certain change or baseline? I am looking into something like rebase to a composite baseline in ClearCase. Thanks Jirong |
You may want to look at the post build deliver feature that was added in 3.0.1. We are still using CruiseControl to do the actual build, and looking into scm commands to retrieve the code from RTC.
In case of build, we don't need to create a workspace from the snapshot, so why we want to create one during the build? I may want to create a snapshot for each release, so later on I can create a new stream or workspace from there to fix a bug or for deployment,etc. Thanks Jirong |
|
I'm confused as to what you want to do with the snapshot. You said the developers will accept the baselines from the snapshot. Creating a workspace from a snapshot will accomplish this.
I think the best practice is to baseline changes and push it to a stream that would be the input to the build. You can still create the snapshot for the build and change owner to the stream (promote isn't the term for moving snapshots around anymore). The snapshot would use the baselines created by the user. With this method, the user knows what is being put into the build and controls what is delivered to the stream that is used for the build. Developers will recognize baselines from this stream as what was used in builds. |
I'm confused as to what you want to do with the snapshot. You said the developers will accept the baselines from the snapshot. Creating a workspace from a snapshot will accomplish this. I don't want to use snapshot. To me, this snapshot is almost useless if it can't be delivered. But you guys keep on referring to this snapshot so I am trying to figure out how can I use it. What I want to achieve is simple like in old ClearCase day: 1. I create a composite baseline in the integration stream. 2. My R/O build stream rebase to the above composite baseline. 3. I run build against the above composite baseline. 4. If success, developers rebase to the above composite baseline. I try to use the snapshot to constitute the above composite baseline in RTC, but: 1. If I create a snapshot in the build workspace, I can't deliver it to the integration stream. 2. If I create a snapshot in the integration stream, can developers kind of "rebase" to that? I don't want to create any workspaces during the build, because all workspaces are already there. Thanks Jirong |
|
I'm not sure what you mean by delivering a snapshot. You can't collaborate with a snapshot so that means you can't deliver from a snapshot. This is why I suggested creating a workspace from the snapshot. You may then set the flow target on the workspace to deliver any changes/baselines.
I don't think you need to create a snapshot for what you want to do. It sounds like you want to baseline all the components instead of creating the snapshot to get your baselines. I would do this: 1. Sync your build workspace to the integration stream. 2. Baseline each component. 3. Load content from workspace to perform the build activities. 4. Deliver baselines from workspace if build is successful. For incremental builds, compare the build workspace to the stream and continue the build if there are new change sets. This would be the same as selecting the option to build only if changes are accepted when using JBE. |
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.