How Do I set up a Build Stream for my Project?
I have been working through the JUNIT RTC example and have found it very useful. We have an environment that is similar to that example. Since I am new to RTC. I would like someone to verify that I am on the right path, or suggest a better path if there is a better approach.
Here is our process:
We have 2 development teams - India and US but currently we use a single stream and do all the work there. We could create 2 streams, and split our development and then have an integration stream like the example, but that seems to be a lot of overhead and merging with little value add.
We do need a stable stream though, that we can have a "transport" person deliver to for our test builds. In our group, this person is not a programmer. They only follow a simple process to move code from one environment to another.
In our current "CMVC" environment this person adds a Defect or Feature to a level and then runs a build. I think we can do the same thing by having this person deliver from one stream to another and then run a build. The key here is that the developers cannot do the moves, and the transporter cannot do a merge.
So I have two processes in mind, and would like some input on whether either one woould work, which is better, or if I am on the wrong track.
1) Have a US and India Dev team, each with separate streams and the can deliver to an Integration stream to do the merge, and then have the transporter deliver from the Integration stream to the Test Stream and do the build from there.
2) Have one team with all the Developers working in one stream and then have the transport person deliver directly from there to the Test Stream.
The first seems like more work and more complicated, but the second seems to be riskier. We do not want to end up delivering in progress code to test by mistake.
We need our process to be both stable and straightforward.
Here is our process:
We have 2 development teams - India and US but currently we use a single stream and do all the work there. We could create 2 streams, and split our development and then have an integration stream like the example, but that seems to be a lot of overhead and merging with little value add.
We do need a stable stream though, that we can have a "transport" person deliver to for our test builds. In our group, this person is not a programmer. They only follow a simple process to move code from one environment to another.
In our current "CMVC" environment this person adds a Defect or Feature to a level and then runs a build. I think we can do the same thing by having this person deliver from one stream to another and then run a build. The key here is that the developers cannot do the moves, and the transporter cannot do a merge.
So I have two processes in mind, and would like some input on whether either one woould work, which is better, or if I am on the wrong track.
1) Have a US and India Dev team, each with separate streams and the can deliver to an Integration stream to do the merge, and then have the transporter deliver from the Integration stream to the Test Stream and do the build from there.
2) Have one team with all the Developers working in one stream and then have the transport person deliver directly from there to the Test Stream.
The first seems like more work and more complicated, but the second seems to be riskier. We do not want to end up delivering in progress code to test by mistake.
We need our process to be both stable and straightforward.
8 answers
I always start with whatever is simplest, and only add in additional
streams when needed.
So I'd start with a single development stream, and a single stable
stream. Then write down explicitly what is the criteria that must be
met for a configuration to be delivered to the stable stream.
As for delivering in-progress code, there is no reason for people to be
delivering in-progress code to the development stream. They would keep
that code private in their workspace, and only deliver it to the
development stream when they are done with a particular change.
Cheers,
Geoff
StanCason wrote:
streams when needed.
So I'd start with a single development stream, and a single stable
stream. Then write down explicitly what is the criteria that must be
met for a configuration to be delivered to the stable stream.
As for delivering in-progress code, there is no reason for people to be
delivering in-progress code to the development stream. They would keep
that code private in their workspace, and only deliver it to the
development stream when they are done with a particular change.
Cheers,
Geoff
StanCason wrote:
I have been working through the JUNIT RTC example and have found it
very useful. We have an environment that is similar to that example.
Since I am new to RTC. I would like someone to verify that I am on
the right path, or suggest a better path if there is a better
approach.
Here is our process:
We have 2 development teams - India and US but currently we use a
single stream and do all the work there. We could create 2 streams,
and split our development and then have an integration stream like
the example, but that seems to be a lot of overhead and merging with
little value add.
We do need a stable stream though, that we can have a
"transport" person deliver to for our test builds. In our
group, this person is not a programmer. They only follow a simple
process to move code from one environment to another.
In our current "CMVC" environment this person adds a Defect
or Feature to a level and then runs a build. I think we can do the
same thing by having this person deliver from one stream to another
and then run a build. The key here is that the developers cannot do
the moves, and the transporter cannot do a merge.
So I have two processes in mind, and would like some input on whether
either one woould work, which is better, or if I am on the wrong
track.
1) Have a US and India Dev team, each with separate streams and the
can deliver to an Integration stream to do the merge, and then have
the transporter deliver from the Integration stream to the Test
Stream and do the build from there.
2) Have one team with all the Developers working in one stream and
then have the transport person deliver directly from there to the
Test Stream.
The first seems like more work and more complicated, but the second
seems to be riskier. We do not want to end up delivering in progress
code to test by mistake.
We need our process to be both stable and straightforward.
:D I love it.... The vote at the top is 2 for the more complicated separate development streams and none for the simpler single development stream.
Geoff makes a great argument for the single development stream with the "Keep It Simple Sir" principle.
I am curious about the two votes for the separate development teams.... anyone care to comment on why that might be better?
Geoff makes a great argument for the single development stream with the "Keep It Simple Sir" principle.
I am curious about the two votes for the separate development teams.... anyone care to comment on why that might be better?
...As for delivering in-progress code, there is no reason for people to be delivering in-progress code to the development stream. They would keep that code private in their workspace, and only deliver it to the development stream when they are done with a particular change...
The reason we deliver in-progress code to the development environment is that frequently we have multiple developers working on the same defect. We also have code reviews of the work and make suggestions to our new developers for improvements or reusable components that may have been missed. Our only requirement for the development stream is that it must compile! This allows our team to work together on in-progress code.
Only when the code is complete, reviewed, and unit tested, do we place the request to our transport person to deliver the "fix" to test.
StanCason wrote:
You don't need to deliver in-progress code to the development stream in
order to collaborate on a defect. It's possible to accept change sets
into your workspace directly from someone else's workspace. Or if there
are too many change sets flowing around you could set up a new stream
for work on just that one defect.
Streams and workspaces are relatively lightweight. It is easy to create
new ones for a short-term project and then delete them once the changes
have been delivered to the product's integration stream.
You don't need to deliver code to the development stream in order to do
code reviews. Any change that has been checked into a workspace is
visible to the team (though it might take a bit of searching to find
it). The policy on our team is that all changes much be code reviewed
before they are delivered. RTC makes it very easy to do that.
You should consider strengthening that requirement. With personal
builds it is quite easy to test your changes before delivering, which
removes any good excuse for delivering a change that breaks the product.
(For some teams it is difficult for personal builds to adequately test
the product. So I'm just suggesting that you consider strengthening the
requirement, not insisting that it's the right thing to do.)
It should be possible for developers to do all of that in their own
workspaces before delivering. I really think you should consider having
just one stream, not two or four.
The reason we deliver in-progress code to the development environment
is that frequently we have multiple developers working on the same
defect.
You don't need to deliver in-progress code to the development stream in
order to collaborate on a defect. It's possible to accept change sets
into your workspace directly from someone else's workspace. Or if there
are too many change sets flowing around you could set up a new stream
for work on just that one defect.
Streams and workspaces are relatively lightweight. It is easy to create
new ones for a short-term project and then delete them once the changes
have been delivered to the product's integration stream.
We also have code reviews of the work and make suggestions to
our new developers for improvements or reusable components that may
have been missed.
You don't need to deliver code to the development stream in order to do
code reviews. Any change that has been checked into a workspace is
visible to the team (though it might take a bit of searching to find
it). The policy on our team is that all changes much be code reviewed
before they are delivered. RTC makes it very easy to do that.
Our only requirement for the development stream is
that it must compile!
You should consider strengthening that requirement. With personal
builds it is quite easy to test your changes before delivering, which
removes any good excuse for delivering a change that breaks the product.
(For some teams it is difficult for personal builds to adequately test
the product. So I'm just suggesting that you consider strengthening the
requirement, not insisting that it's the right thing to do.)
Only when the code is complete, reviewed, and unit tested, do we place
the request to our transport person to deliver the "fix" to
test.
It should be possible for developers to do all of that in their own
workspaces before delivering. I really think you should consider having
just one stream, not two or four.
Thanks for your reply! This really sounds intrigung.. Forgive my ignorance here, I am still a beginner on a steep learning curve.
I think you are saying that there is a big difference between check-in and deliver.
I hope this doesn't throw a monkey wrench into the mix, but we need to do builds of a development and test environment. I thought I could only do a build from a stream.
The development environment needs to be built every 3 hours and should contain all checked in code.
The test environment needs to be built only on demand and will contain only code delivered to the test stream.
We are doing WAS builds using ANT to build the EAR files and automatically deploying thenm on a remote WAS server and then restarting the WAS application server.
I think you are saying that there is a big difference between check-in and deliver.
I hope this doesn't throw a monkey wrench into the mix, but we need to do builds of a development and test environment. I thought I could only do a build from a stream.
The development environment needs to be built every 3 hours and should contain all checked in code.
The test environment needs to be built only on demand and will contain only code delivered to the test stream.
We are doing WAS builds using ANT to build the EAR files and automatically deploying thenm on a remote WAS server and then restarting the WAS application server.
StanCason wrote:
It doesn't matter so much what approach you pick, as long as you
reevaluate your decision after a couple months and are willing to change
your approach if you don't like your initial pick. Streams are
lightweight enough that changing from one approach to the other
shouldn't be too hard.
But I agree with Geoff that you should start by keeping it simple. It
is easier to start with a simple process and then add complexity later
if the simple process doesn't work than it is to start with a complex
process and then make it simpler later.
:D I love it.... The vote at the top is 2 for the more complicated
separate development streams and none for the simpler single
development stream.
Geoff makes a great argument for the single development stream with
the "Keep It Simple Sir" principle.
I am curious about the two votes for the separate development
teams.... anyone care to comment on why that might be better?
It doesn't matter so much what approach you pick, as long as you
reevaluate your decision after a couple months and are willing to change
your approach if you don't like your initial pick. Streams are
lightweight enough that changing from one approach to the other
shouldn't be too hard.
But I agree with Geoff that you should start by keeping it simple. It
is easier to start with a simple process and then add complexity later
if the simple process doesn't work than it is to start with a complex
process and then make it simpler later.
StanCason wrote:
Yes, there is a big difference between check-in and deliver. It is
vital that you understand the difference. When you check in a change,
it is checked into the repository workspace that you are currently
using. The changes are stored on the server, but they are kept local to
your personal workspace and are not readily available to others. When
you deliver a change set it is copied from your repository workspace to
a stream. Once the change set is in a stream, it is readily available
to anyone whose workspace accepts changes from that stream. So in short:
check-in = store the change on the server
deliver = make the change available to everyone
You can only do a build from a workspace, not a stream. But the usual
setup is that the first thing the build does is accept changes from the
steam into the workspace. So with the usual setup, for all intents and
purposes the build is building from a stream.
But it also possible (and extremely useful) to do a personal build.
With a personal build you tell the build system to not use the usual
build workspace but instead use your own personal workspace. The step
of accepting changes into the workspace is skipped, so the build builds
exactly what it is in your workspace. Personal builds are often run
just before you plan to deliver your changes as a way to make sure your
changes won't break the build.
There is no way to automatically build all checked in code. You can
only automatically build code that has been delivered to a stream. You
can build code that has been checked in but not delivered, but it has to
be done on demand with a personal build. It doesn't happen automatically.
Why build every three hours? Why not build whenever a change is
delivered to the stream? It's easy enough to set up your build that way.
RTC is quite different, and probably a lot better, at collaborative
software development than any tool you have used before. When moving to
RTC you should reevaluate your development process and procedures and
look for ways to take advantage of RTC to improve your process. Don't
try to force your existing process into RTC. Instead figure out how RTC
can make your process better. This will be an ongoing thing, since you
can't know enough about how RTC works to make all the right choices up
front. But it is important to have the attitude of continuous
improvement going in.
I think you are saying that there is a big difference between check-in
and deliver.
Yes, there is a big difference between check-in and deliver. It is
vital that you understand the difference. When you check in a change,
it is checked into the repository workspace that you are currently
using. The changes are stored on the server, but they are kept local to
your personal workspace and are not readily available to others. When
you deliver a change set it is copied from your repository workspace to
a stream. Once the change set is in a stream, it is readily available
to anyone whose workspace accepts changes from that stream. So in short:
check-in = store the change on the server
deliver = make the change available to everyone
I hope this doesn't throw a monkey wrench into the mix, but we need to
do builds of a development and test environment. I thought I could
only do a build from a stream.
You can only do a build from a workspace, not a stream. But the usual
setup is that the first thing the build does is accept changes from the
steam into the workspace. So with the usual setup, for all intents and
purposes the build is building from a stream.
But it also possible (and extremely useful) to do a personal build.
With a personal build you tell the build system to not use the usual
build workspace but instead use your own personal workspace. The step
of accepting changes into the workspace is skipped, so the build builds
exactly what it is in your workspace. Personal builds are often run
just before you plan to deliver your changes as a way to make sure your
changes won't break the build.
The development environment needs to be built every 3 hours and should
contain all checked in code.
The test environment needs to be built only on demand and will contain
only code delivered to the test stream.
There is no way to automatically build all checked in code. You can
only automatically build code that has been delivered to a stream. You
can build code that has been checked in but not delivered, but it has to
be done on demand with a personal build. It doesn't happen automatically.
Why build every three hours? Why not build whenever a change is
delivered to the stream? It's easy enough to set up your build that way.
RTC is quite different, and probably a lot better, at collaborative
software development than any tool you have used before. When moving to
RTC you should reevaluate your development process and procedures and
look for ways to take advantage of RTC to improve your process. Don't
try to force your existing process into RTC. Instead figure out how RTC
can make your process better. This will be an ongoing thing, since you
can't know enough about how RTC works to make all the right choices up
front. But it is important to have the attitude of continuous
improvement going in.
On the question of code reviews, we commonly require that there be a
code review *before* delivery to the team stream, especially when we are
in the final set of iterations. This is done just by having the
developer add an approval to the work item when they are ready for it to
be approved. The request for approval then shows up in email to the
approver (so there is no need for the approver to go searching for it).
Note that you can enforce this requirement by configuring your process
in your project or team area.
Cheers,
Geoff
David Olsen wrote:
code review *before* delivery to the team stream, especially when we are
in the final set of iterations. This is done just by having the
developer add an approval to the work item when they are ready for it to
be approved. The request for approval then shows up in email to the
approver (so there is no need for the approver to go searching for it).
Note that you can enforce this requirement by configuring your process
in your project or team area.
Cheers,
Geoff
David Olsen wrote:
StanCason wrote:
The reason we deliver in-progress code to the development environment
is that frequently we have multiple developers working on the same
defect.
You don't need to deliver in-progress code to the development stream in
order to collaborate on a defect. It's possible to accept change sets
into your workspace directly from someone else's workspace. Or if there
are too many change sets flowing around you could set up a new stream
for work on just that one defect.
Streams and workspaces are relatively lightweight. It is easy to create
new ones for a short-term project and then delete them once the changes
have been delivered to the product's integration stream.
We also have code reviews of the work and make suggestions to
our new developers for improvements or reusable components that may
have been missed.
You don't need to deliver code to the development stream in order to do
code reviews. Any change that has been checked into a workspace is
visible to the team (though it might take a bit of searching to find
it). The policy on our team is that all changes much be code reviewed
before they are delivered. RTC makes it very easy to do that.
Our only requirement for the development stream is
that it must compile!
You should consider strengthening that requirement. With personal
builds it is quite easy to test your changes before delivering, which
removes any good excuse for delivering a change that breaks the product.
(For some teams it is difficult for personal builds to adequately test
the product. So I'm just suggesting that you consider strengthening the
requirement, not insisting that it's the right thing to do.)
Only when the code is complete, reviewed, and unit tested, do we place
the request to our transport person to deliver the "fix" to
test.
It should be possible for developers to do all of that in their own
workspaces before delivering. I really think you should consider having
just one stream, not two or four.