Branching question
in RTC we do not have streams like in clearcase. Where all the devl works on devl stream and than the code is delivered to integration stream. The code is baselined on integration stream and build/deploy happens from integration stream. The developer keeps on working on devl stream.
How is this done in RTC ?
1. developers have to deliver the code on the streams eg: main stream
2. build/deploy has to happen from main stream
3. builds for devl, test, QA and prod happens from same stream
4. how do we manage that certain defects delivered and not working correctly and should not make it to prod ? is roll back is the only option ? roll backs are pain in RTC specially when the same files as been modified by more than one developer.
How do we perform parallel development ? what strategy works best for parallel development ?
if we create 2 streams MAIN and BRANCH how the delivery between streams are managed ?
How is this done in RTC ?
1. developers have to deliver the code on the streams eg: main stream
2. build/deploy has to happen from main stream
3. builds for devl, test, QA and prod happens from same stream
4. how do we manage that certain defects delivered and not working correctly and should not make it to prod ? is roll back is the only option ? roll backs are pain in RTC specially when the same files as been modified by more than one developer.
How do we perform parallel development ? what strategy works best for parallel development ?
if we create 2 streams MAIN and BRANCH how the delivery between streams are managed ?
5 answers
Still to get all the changes from all the developers in the workspace the source code has to be delivered to the main stream before the build can be done.
so still if some of the code is not required to go to prod has to be rolled out which is pain i think.
Other option would be to create 2 stream Main-devl and Branch-prod and Keep delivering the required QA passed workitem from Main to Branch so build can be done from branch for prod
is there any other good way ?
so still if some of the code is not required to go to prod has to be rolled out which is pain i think.
Other option would be to create 2 stream Main-devl and Branch-prod and Keep delivering the required QA passed workitem from Main to Branch so build can be done from branch for prod
is there any other good way ?
Still to get all the changes from all the developers in the workspace the source code has to be delivered to the main stream before the build can be done.
so still if some of the code is not required to go to prod has to be rolled out which is pain i think.
Other option would be to create 2 stream Main-devl and Branch-prod and Keep delivering the required QA passed workitem from Main to Branch so build can be done from branch for prod
is there any other good way ?
I guess we are mixing concepts here.
1. In branching strategies, each branch has to have a clear purpose. So now what's your purpose of main branch? You try to use it as the integration stream and at the same time "park" the production baselines. To me, the 2nd is not necessary.
2. Rollback is not usually the actual way to fix a build. Usually we always go forward to fix the build errors. Mean fix in dev and deliver again.
Jirong
Hi Jirong,
right we should always move forward to fix the build but there may be a situation that the fix works in the developers local copy but fail when delivered to the stream and if you have a fix date/time for uat/prod build and the developer is not able to figure out why it is not working when delivered the code to stream before the deadline he needs to roll it back. We want to avoid this situation and are looking for a way how can we achieve this. ?
right we should always move forward to fix the build but there may be a situation that the fix works in the developers local copy but fail when delivered to the stream and if you have a fix date/time for uat/prod build and the developer is not able to figure out why it is not working when delivered the code to stream before the deadline he needs to roll it back. We want to avoid this situation and are looking for a way how can we achieve this. ?
Hi Jirong,
right we should always move forward to fix the build but there may be a situation that the fix works in the developers local copy but fail when delivered to the stream and if you have a fix date/time for uat/prod build and the developer is not able to figure out why it is not working when delivered the code to stream before the deadline he needs to roll it back. We want to avoid this situation and are looking for a way how can we achieve this. ?
Then you have to have an intermediate integration stream. You can look into this article.
https://jazz.net/library/article/649