How can parallel development (e.g. gitflow) be done with RTC?
I have been working with the so called gitflow for years and this workflow is pretty standard for open source development (e.g., on github). [Short summary for the easy version=Branching workflow: For each new feature, a branch is created and used for development; after finishing the feature, there is a review (so called pull request) to merge them back to main branch. Typically, feature branches can only live for a few days. Plus, the development is parallel, i.e., many files are modified on several branches at the same time. Until now, we have used the integration solution of Jira plus Bitbucket.]
We are now going to to use RTC and want to use the same workflow but observed some difficulties. I hope someone can help us solving them! We have found an article on ibm.com about how it is done in RTC: which we used as blueprint for our test of the workflow. If there is a better way to do it, please let us know!
1) When creating a new stream, this has to be done by hand, and we have to manually keep in mind to which work item it belongs to. Is there a way that the stream is automatically generated and automatically linked to the corresponding work item?
2) When there are a lot of changed on the main stream, I want to merge them into the feature branch on a regular basis in order to get merge conflicts as small as possible and in order to test the new feature in the overall context which is as near as possible on the desired status. a) Is there a better way to do this than setting the current connected stream of the workspace repository to the main stream? b) For the merge commit, I am asked for a work item number. Which one do I have to give? (The changed are not in the scope of the current work item on this stream, so I don't want to give this one; but I don't want to search which work items correponds to the changes on the main stream and I there could be a lot in a bigger project). How can I solve this problem?
3) Before deploying the changed of the feature back into the main stream, we want to ensure that the software is stable, e.g., a review must be performed. We observed some problems with the current IBM review tool if there is an intermediate commit (e.g., the merge from above) if it is linked to another work item. However, if we link the merge to the current work item, these changes are also displayed in the review. Is there a better way to do it? I have already seen another question in this forum related to this questions, but this seems to be a big overhead (new work item, manual linkage between them, manual adding change sets together, ...). If the linkage between all those artefacts could have done completly automatically, this workflow could be fine. But if this is not as much automated as possible, errors could occur.
4) For merging, someone has to manually change the current stream of his workspace repository to merge the changes which could also lead to errors. Is there a better way to do it?
5) In order to better track all changes and keep the history of context the changesets were merged into the main stream, we want to build a snapshot and link it to the corresponding work item: a) At the time the stream was created, b) after the stream was merged into the main stream. Is there a possibility to do this automatically?
6) It is typical that a user works on several features at the same time. What is the best solution to switch the streams as fast and (more important) as safe as possible. Our safest solution was to create a seperate workspace repository for each new stream (which has the drawback that I have to download the stream and that pre-compiled files are gone for a local build). Is there a better way to do it?
Thank you very much for your help! Maybe you even have a better solution to get this workflow running with RTC.
Accepted answer
https://jazz.net/library/article/539
https://jazz.net/library/article/126
https://jazz.net/library/article/1481
1) A stream and a work item dont't have any relationship. A stream is just something a team develops against. It contains changes based on the components and their baselines selected. You can use the SCM command line to create streams, but I think you mix up concepts here.
2) There is no main stream or branch. Each stream is just a stream. We don't have a main branch and forget that concept. Setting the flow target and merging is the method RTC uses.
3) Can't comment to that. You could use roles, team areas and delivery permissions to protect your stream
4) That is how it works.
5) There is no first class relationship from a snapshot or baseline to a work item. If you want to automate something like that, you would have to create an automation or try to use the SCM commandline (I don't think this provides all you needed either).
6) Multiple workspaces or load/unload To be efficient a user would work only on very few features (ideally one) because context switching is as expensive for a brain as it is for a CPU, maybe more.
Comments
Hello Ralph, thanks for your answer and the new links! Just to clarify my question 2): I know that all streams are technically equal as it is in git. I was just refering to the linked article on IBM.com where they used the term "main stream" for that stream releases are made (or the whole project is developing against). Let call that "StreamA" and the other one "StreamB".
Let's say, at time=0, both streams contain the same content, and someone is developing a new feature in StreamB (with work item id 123) for some time in some change sets. In the meantime, someone else have change something on StreamA in the same files (maybe there was a hotfix or an interface change, or both). Now, I want to merge the changes from StreamA to StreamB (because I don't want to solve potential merge conflicts too late, and I want to test the software on StreamB which is as close as possible to the deserved software after everything in StreamB will be merged in StreamA at the end). For this merge (StreamA -> StreamB), RTC is asking me for a work item id. Which one do I have to take?
Let the work item aside first.
You have a workspace that is at par with Stream B (Feature Stream). To integrate the changes point the workspace to Stream A and accept/merge changes in. You can test and build on your repository workspace until you are satisfied.
With respect to delivering the integration to Stream B. All work done for the "main development" would have a work item already. So what is left is the merge work. I personally would assume that being work for the feature, but using a feature work item or an entirely new one for "Feature Integration" is really just something that you will have to agree on in your department.