Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a Rtc Stream Stratagies
Semelhante a Rtc Stream Stratagies (20)
Rtc Stream Stratagies
- 1. Stream Strategies Powered by RTC Date: 21.3.12 Author: Liora Milbaum
- 2. Single Stream Development • "straight line development“ • simplest form of software development • small teams and organizations • all work is delivered to a single stream, which is associated with the project/team
- 3. Single Stream Development – Fig. 1
- 4. Naming Conventions • Components – “Xxx_comp” for example Acme_comp • Streams – “Xxx-xxx” for example Acme-dev, Acme- integ, Acme-rel-3.0 • Workspaces – “proj_wkspc_userid_xx” for example Acme_wkspc_dtoczala_dev, Acme_wkspc_integration_build • Plans – “desc time plan” for example Acme Sprint 1 Plan, Acme Release 2.0 Plan, Jade Team Sprint 7 Plan
- 5. Multiple Release Development • the team is working on release X, but still needs to support and do maintenance for releasex-1, x-2, and so on • a dedicated development stream. • maintenance streams begin with the released baselines
- 6. Multiple Release Development – Fig 2.
- 7. Multiple Release Development – Fig. 3
- 8. Multiple Application Development • large scale development efforts • development of multiple software components or applications • streams are used to segregate development efforts, and to control development environments
- 9. Multiple App Development – Fig 4
- 10. Demo – Add a Comp to Wkspc • open your workspace • add the "missing" component to your workspace • save the workspace. • load that component into your sandbox • do not make changes to that component, because you will not be able to deliver them to the stream
- 11. Demo – Add a Comp to Wkspc • Can Dan deliver changes of the Gamma_Comp to the Gamma development stream, and changes to Acme_Comp to the Acme development stream? Yes he can • He would need to deliver any Acme component based change sets to that development stream, and any Gamma component based change sets to the Gamma development stream. So he would deliver first to one stream, and then repoint his workspace at the second stream.
- 12. UC1 – Small Team Multiple Comp
- 13. UC1 – Large Team Multiple Comp
- 14. UC2 – A workspace or a stream
- 15. Q/A & Discussion Date: 21.3.12 Author: Liora Milbaum
Notas do Editor
- We sometimes refer to single stream development efforts as "straight line development". This is the simplest form of software development, and it requires the least amount of administration and oversight. It is easy to set up, easy to understand, and works for well for small teams and organizations. We often see this style of stream strategy with IT shops, R&D efforts, and with teams that have an ongoing application maintenance effort.
- In single stream development, all work is delivered to a single stream, which is associated with the project/team. Developers create one or more workspaces which deliver to this stream, as well as the sandboxes on their local machines which are related to these workspaces. Each developer/contributor works in their sandbox, and will check in their changes to their repository workspace. As change sets are created, they are associated with work items. When these work items are completed, their associated change sets are then delivered to the project/team stream, and a new baseline may be created.At this point these changes then become visible to the remainder of the team, who then will accept the incoming change sets. Figure 1 is a diagram of what a single stream strategy looks like when visualized in RTC. Note how each workspace is associated with an individual developer, tester, analyst or stakeholder, and all workspaces have the same project/team stream as their delivery target.So each of the users (Alan, Deb, Dan, Don and Tim) has their own repository workspace. Any changes that they check in are only visible to them, and are stored in their repository workspace. Once those changes are ready to be shared with the rest of the team, they are delivered to the team stream (Acme Stream), and they will then appear as incoming changes for the remaining team members.
- I need to take a slight detour here to address naming conventions. Naming conventions are critical to a successful deployment of Jazz. The tools don't care what you name things, but since HUMANS need to interact with the tools, naming conventions become a critical piece of the solution. Good naming conventions will allow anyone interacting with the software development environment to easily navigate and find the files, information, and data that they are looking for. Table 1 shows a sample of some naming conventions that I have seen in use with organizations using RTC.The key to having useful and successful naming conventions is to have everyone using those naming conventions. They should be simple to remember, simple to use, and ease the understanding of the people using the tools. Complicated naming conventions get ignored. Don't worry about handling every possible case with your naming conventions, that will make them too complex. There will always be exceptions to the naming conventions, just make sure the the goal of having naming conventions is met. The goal of this is to make things easier for the people using the software development environment.
- In multiple release development, developers may be expected to work on the new release, work on maintenance (bug fixes), or both. Developers will have to determine where most of their work is being done, so they can decide on how many Jazz workspaces to use, and where to base those workspaces. Teams need to have strong naming conventions for their streams and workspaces, in order to maintain a sense of order, and so everyone can easily find the things that they might be looking for. So once you have some good naming conventions in place, for the software components, the stream, and the workspaces, it is time to begin organizing those streams.
- Just looking at what we see in Figure 2, we can immediately see how things are being done. I see the Acme development stream at the middle of this diagram, labeled as Acme-Development. I can see that Tim has a workspace that is based on the Acme development stream (called Acme_wkspc_tim_dev), and that his current and default targets for the delivery of any changes is the Acme development stream. Don and dtoczala have workspaces with similar relationships to the Acme development stream.The interesting cases are those of Deb and Alan. Deb has a workspace (Acme_wkspc_deb_dev) that shows a dotted line relationship to the Acme development stream, but has a solid line and default relationship to the Release 1.0 stream, called Acme-release-1-0. The default tag indicates that this is her default delivery target, and the solid line indicates that this is also her current delivery target.When we look at Alan's workspace, we see that it is similar to the situation Deb is in, with Alan's current delivery target being the Release 1.0 stream. What is different is that Alan's default target for delivery is the Acme development stream (you can see the label on that arrow).
- Following the delivery, we have a new stream called Acme-release-1-1, which represents the code in the 1.1 release of our Acme component. Note that Deb now is doing maintenance work on Acme release 1.1, and Alan is doing maintenance work on Acme release 1.0. Both Dab and Alan have dotted lines coming from their workspaces, indicating that they also deliver change sets to alternative targets. The remainder of the team is still delivering their work to the Acme development stream.One thing to note in Figure 3 is the direction of the flow of changes. In this scenario we show the changes flowing from the development stream to the two maintenance streams. The arrows could just as easily be pointing in the opposite direction, it just depends on where you initially make changes. In this scenario, we make our changes on the code currently being developed, and then flow those changes to the maintenance streams. In the case of Alan and Deb, they may deliver their changes to the maintenance stream first, and then deliver those same change sets to the current development stream. What is important here is that you show the relationships between the streams.We typically recommend that changes flow from maintenance streams to the current development stream, since this is the way the work is typically done (I deliver my maintenance fix first, then I incorporate that fix into the current development stream). RTC will support flowing changes in either direction, so choose the one that best fits the way that you develop and maintain your software.Another thing to note is the relationship between the streams. When you indicate a flow target for a stream, you must realize that this is just the identification of a relationship. There are no enforced semantics that are associated with this relationship. You cannot deliver changes from one stream to another.The key here is the use of baselines (and snapshots) to identify key configurations. Each stream will have their own set of component baselines, which should represent the stable state of the stream at different points in time.
- In this example I am showing the workspace owners, and not the workspacenames. You can control this by checking and unchecking the "Show name instead of owner" checkbox in the Properties tab when you click on the workspace in the diagram.Here we see our developers dedicated to the development of a single software component or application. Alan is working on the Acme development effort, and Don is working on the Beta development effort. Development in each of these streams occurs only on those individual components. The Systems integration stream, called System-int, then uses changes from each of these development streams, and the integration of the components (or applications) is done in this stream.Sometimes these efforts on the individual components will require visibility to the other components available to the project. If you look at Dan's workspace in the lower right of Figure 4, you will notice that Dan has both the Acme_comp and Gamma_comp in his workspace, but only the Gamma_comp component is available in the Gamma development stream. Dan will be able to build and test his work, but will be unable to deliver any changes to the Acme_comp component.With this type of strategy, teams can work in isolation and integration activities can be coordinated without slowing development of the individual components or applications.
- The previous examples are geared towards a large-scale development team. Consider Figure 1 and Figure 4 in light of a smaller development team (let's say five people). Also let's use example component names of "Client", "Server", and "Test" instead of alpha/beta/gamma.A small team would have one stream "Acme Integration". It would contain the three components "Client", "Server", and "Install". Dan and Alan are server developers so they only load "Server". Deb is a client developer and loads "Client". Tim does install loading "Install". Don is the team lead and has his hands in everything, so he loads all three components. (This is the modified figure 1).Fast-forward in time. The Acme project is wildly successful and there is a new feature list five miles long. Don's manager hires thirty new developers and puts ten on each component. Now, figure 4 makes a lot more sense. Don our trusty team lead is promoted to architect. He sets up three streams so that each group of developers can work in isolation from the others. Don is in charge of integrating changes from the individual streams into the main integration stream. Alan, Deb, and Tim are appointed component leads and maintain the individual streams. The other 30 developers only load the one component they need visibility to.
- The previous examples are geared towards a large-scale development team. Consider Figure 1 and Figure 4 in light of a smaller development team (let's say five people). Also let's use example component names of "Client", "Server", and "Test" instead of alpha/beta/gamma.A small team would have one stream "Acme Integration". It would contain the three components "Client", "Server", and "Install". Dan and Alan are server developers so they only load "Server". Deb is a client developer and loads "Client". Tim does install loading "Install". Don is the team lead and has his hands in everything, so he loads all three components. (This is the modified figure 1).Fast-forward in time. The Acme project is wildly successful and there is a new feature list five miles long. Don's manager hires thirty new developers and puts ten on each component. Now, figure 4 makes a lot more sense. Don our trusty team lead is promoted to architect. He sets up three streams so that each group of developers can work in isolation from the others. Don is in charge of integrating changes from the individual streams into the main integration stream. Alan, Deb, and Tim are appointed component leads and maintain the individual streams. The other 30 developers only load the one component they need visibility to.
- It is also possible to use a repository workspace as a team area, rather than a stream.What are the pros and cons of using a repository workspace rather than a stream?You can use a repository workspace the same way that you would use a stream, but with this model everything that I check in will become immediately visible to the rest of my teammates. Even if it doesn't compile. You also run a stronger risk of creating dependencies between work items. Take the case where you and I are working on file "foo". If we each have our own repository workspaces, attached to the same stream, then I can check in my changes 2, 5, or 500 times, and you do not see my changes until I either deliver them to the stream, or (if you want to see them before delivery) until you apply my change set to your repository workspace.If we both have our local workspace (sandbox) connected to the repository workspace, then our changes to "foo" are immediately visible to the other developer. What is worse, is that if I change "foo", then you change "foo", and then I change "foo" some more, then we have creatd a situation where I am unable to deliver my change set unless you change set is delivered at the same time (since my second change may depend on your changes). If we are each in our own repository workspaces, then this is not an issue.
- לסיכום, דעתי האישית היא שהבחירה צריכה להתבצע בעיקר לפי סביבת העבודה של המפתח, מערכת ההפעלה והIDE איתם הוא עובד.