Welcome to the Jazz Community Forum
SCM: What's the RTC analogue for "Tag, then build"
I have a couple of questions concerning the SCM.
Our current setup is as follows:
We have a continuous integration build working with a specific build workspace. On this build workspace the JBE is creating baselines and snapshots for each (non-personal) build.
Now let's say the team wants to create a release. This release will be the basis for a new bugfixing development line (= a new stream).
What is the best practice for creating a release?
In the CVS world we would usually tag all our modules and then create a build from the tag. Later on you would then create a branch from the release tag and commit bugfixes to the branch.
Idea 1:
1. Create a new workspace from the stream and create a snapshot on it.
2. Deliver the created baselines back to the stream.
3. Promote the snapshot.
4. Somehow get the build to use this snapshot (by creating a new workspace from a new stream?)
Idea 2:
Flag the ant build to execute additional post-build steps:
1. Promote the snaphot to the stream
2. Deliver the changes (would deliver the baselines, right?)
The build has been happily creating baselines for each CI-build. Would these also be delivered or is only the last created baseline delivered?
What are the best practives for creating baselines? When do a really need them?
Isn't it sufficient to have a snapshot in most cases? I mean I
can create a new stream (e.g. for bugfixing) using components from a given snapshot.
Our current setup is as follows:
We have a continuous integration build working with a specific build workspace. On this build workspace the JBE is creating baselines and snapshots for each (non-personal) build.
Now let's say the team wants to create a release. This release will be the basis for a new bugfixing development line (= a new stream).
What is the best practice for creating a release?
In the CVS world we would usually tag all our modules and then create a build from the tag. Later on you would then create a branch from the release tag and commit bugfixes to the branch.
Idea 1:
1. Create a new workspace from the stream and create a snapshot on it.
2. Deliver the created baselines back to the stream.
3. Promote the snapshot.
4. Somehow get the build to use this snapshot (by creating a new workspace from a new stream?)
Idea 2:
Flag the ant build to execute additional post-build steps:
1. Promote the snaphot to the stream
2. Deliver the changes (would deliver the baselines, right?)
The build has been happily creating baselines for each CI-build. Would these also be delivered or is only the last created baseline delivered?
What are the best practives for creating baselines? When do a really need them?
Isn't it sufficient to have a snapshot in most cases? I mean I
can create a new stream (e.g. for bugfixing) using components from a given snapshot.
5 answers
Comments below:
On 12/21/2010 4:08 AM, ubreu wrote:
Your build is automatically creating snapshots. Once you have verified
that a given build is suitable for a release, just rename that snapshot
with the name of the release, and "promote" the snapshot to the
integration stream (that just associates the snapshot with the stream,
so it's easy to find).
from that snapshot.
do is step 3.
an operation you perform once you are ready to bless that snapshot as
being the next "release". You don't need to deliver any of these
baselines to the stream ... it is enough to just promote the snapshot.
need, so you never need to manually create baselines for a snapshot.
Cheers,
Geoff
On 12/21/2010 4:08 AM, ubreu wrote:
I have a couple of questions concerning the SCM.
Our current setup is as follows:
We have a continuous integration build working with a specific build
workspace. On this build workspace the JBE is creating baselines and
snapshots for each (non-personal) build.
Now let's say the team wants to create a release. This release will be
the basis for a new bugfixing development line (= a new stream).
What is the best practice for creating a release?
Your build is automatically creating snapshots. Once you have verified
that a given build is suitable for a release, just rename that snapshot
with the name of the release, and "promote" the snapshot to the
integration stream (that just associates the snapshot with the stream,
so it's easy to find).
In the CVS world we would usually tag all our modules and then create
a build from the tag.
Yes, that is automatically done for you by Jazz build system.
Later on you would then create a branch from
the release tag and commit bugfixes to the branch.
Yes, you would do the same in RTC, i.e. create a release-x-bugfix stream
from that snapshot.
Idea 1:
1. Create a new workspace from the stream and create a snapshot on
it.
2. Deliver the created baselines back to the stream.
3. Promote the snapshot.
4. Somehow get the build to use this snapshot (by creating a new
workspace from a new stream?)
Steps 1, 2, and 4 are done automatically by the build. All you need to
do is step 3.
Idea 2:
Flag the ant build to execute additional post-build steps:
1. Promote the snaphot to the stream
2. Deliver the changes (would deliver the baselines, right?)
The build has been happily creating baselines for each CI-build. Would
these also be delivered or is only the last created baseline
delivered?
You would not automatically promote the snapshot in the build. That is
an operation you perform once you are ready to bless that snapshot as
being the next "release". You don't need to deliver any of these
baselines to the stream ... it is enough to just promote the snapshot.
What are the best practives for creating baselines? When do a really
need them?
Isn't it sufficient to have a snapshot in most cases?
A snapshot will automatically create any additional baselines it might
need, so you never need to manually create baselines for a snapshot.
I mean I
can create a new stream (e.g. for bugfixing) using components from a
given snapshot.
Yes, just right click on the snapshot, and select New->Stream_from_Snapshot.
Cheers,
Geoff
Thanks for your answer!
So I get that all all I need to do is promote the snapshot to the main stream from the build workspace.
The new bugfix stream based on that snapshot will contain the baselines that were created automatically by the build. The main stream however will not have those component baselines.
Would it be a best practice to create an additional snapshot on the main stream so that components would get baselined as well? Otherwise components would stay at their initial baseline in the main stream.
So I get that all all I need to do is promote the snapshot to the main stream from the build workspace.
The new bugfix stream based on that snapshot will contain the baselines that were created automatically by the build. The main stream however will not have those component baselines.
Would it be a best practice to create an additional snapshot on the main stream so that components would get baselined as well? Otherwise components would stay at their initial baseline in the main stream.
Why do you care whether the build baselines show up in the baseline
history of the main stream? It is the snapshots that matter.
Cheers,
Geoff
On 12/29/2010 3:23 AM, ubreu wrote:
history of the main stream? It is the snapshots that matter.
Cheers,
Geoff
On 12/29/2010 3:23 AM, ubreu wrote:
Thanks for your answer!
So I get that all all I need to do is promote the snapshot to the main
stream from the build workspace.
The new bugfix stream based on that snapshot will contain the
baselines that were created automatically by the build. The main
stream however will not have those component baselines.
Would it be a best practice to create an additional snapshot on the
main stream so that components would get baselined as well? Otherwise
components would stay at their initial baseline in the main stream.
This is an old thread, but I am trying do something similar today. How do you "promote" a snapshot from a workspace to a stream? I manually created a "gold" snapshot in the build workspace and delivered it to the stream, but that doesn't make it visible at the stream level.
On a meta-level, why is there a distinction between snapshots and baselines?
On a meta-level, why is there a distinction between snapshots and baselines?
Comments
Baselines are what are created in Components. Snapshots are created in streams. For the most part I would think you want Snapshots, and check the box that says create baselines at the same time if you might have a need to work with a component separately from other components. Although I'm having trouble coming up with a scenario where baselines are actually useful.
To answer my own question about how to "promote" a snapshot from a build workspace to a stream, one method to achieve that is to change the "owner" of the snapshot from the build workspace owner to the relevant stream.
Regarding Vince's question about useful scenarios for baselines, I'm not sure I really have any. Earlier in my [still youthful] RTC days, I typically created streams at specific points in time by manually picking component baselines, but these days I am more likely to create a stream directly from a snapshot, now that I know how to do that.
Given that, I would combine Vince's question and my meta question to ask, why bother with baselines at all [as a separate entity]? Why not only have snapshots, assuming the snapshot automatically applies to both stream and components?
Regarding the question, "Why do you care whether the build baselines show up in the baseline
history of the main stream? It is the snapshots that matter," given the number of questions I field, along the lines of "What was in build XYZ?" it would be really nice for build snapshots to be visible at the stream level. Having them visible only at the (build) workspace level is of questionable utility.
history of the main stream? It is the snapshots that matter," given the number of questions I field, along the lines of "What was in build XYZ?" it would be really nice for build snapshots to be visible at the stream level. Having them visible only at the (build) workspace level is of questionable utility.