Agility with Jazz SCM

Editor's Notes

• #2: I want to tell you the story of my current project. We’ve been using Jazz SCM (and RTC) on our project for over a year now since 1.0.0.1, (we’re now on 2.0.0.1) and think it’s given us real agility . I’d like to explain to you a little about how Jazz SCM works , And after that tell you how we use it , and have as a result become more agile .
• #3: When we started off the project over a year ago now there were a few things you need to know: The plan was to use Clear Case, Clear Quest , etc. etc. But there was one guy on the project who’d seen some stuff about the new “Jazz” thing from IBM, and proposed to the team that they use it instead (It was cheaper too – he did the sums) But there was a guy who, whenever he heard folks say “lets use this nice shiny new thing” he’d reply “ Why? What’s so much better about it than Clear Case etc.? We know about Clear Case. We know how to use it, we know how it works, and we know when it breaks. Why rock the boat? ” But because it was cheaper , and because of the enthusiasm of guy who proposed it, it was decided to try Jazz and see how it went. But the critic (lets call him Statler) reserved judgement . He was yet to be convinced.
• #4: (Picture of something with richness of experience – integration. Piece in a jigsaw? Spoke in a wheel? ) It's no longer simply about the files or the SCM system – we’re on the Jazz platform so we get all the integration richness Leverage linking as much as possible between artifacts: builds, defects, plans... => Rich integration into the application life cycle.
• #5: Firstly, I need to be honest . Jazz is different . It’s not your dad’s Clear Case, but it is simple . Its become clear to me that if you get familiar with the Jazz terminology, you’ll get the concepts too . I want to do this in a slightly different way. Lets consider it from one person’s point of view to begin with. Lets call our man “Sergeant Floyd Pepper”. That’s Floyd up there with the bass guitar . He loves to make music. He plays Jazz in a band with a whole bunch of other talented folks. But usually he starts off on his own. He has the basic stuff to start with, and he knows what the problems he needs to solve are. Lets see the simplest things he deals with first . Some call them “notes” but Floyd calls them “changes” .
• #6: The simplest thing that Floyd works with is a “change” A change is a single action on a single file. What Floyds “Jazz” considers a change is pretty broad: Edits Additions Removals (deletion) Moves Renames [Renaming the 'scripts' directory is a name change in the change set. Moving a file is a parent update.] A change (set) records the before and after states of each file . [Content is stored separately and is delta-compressed.]
• #7: But Floyd is too good a Jazz man to be satisfied with just a single “change”. Frequently, he puts a bunch of them together into a riff, or as Floyd says: Changes are “checked into” a change set . Change sets have a comment: “Cool”, “Yeah Man”, “Smooth”, or as we can see here: “Refactored the Domain Model Man. Groovy” Change sets are owned by a component . This is just a logical group of files (i.e. synonymous with an Eclipse or Visual Studio project) Each component instance has a current configuration . This is the set of directories and files that results from applying the change sets in a chronological order. The collection of these modifications into a series of change sets is called the change history . Change sets can be discarded , suspended , and resumed . They are the base currency in the SCM model
• #8: Components are created in order to logically group collections of code and other artefacts. These are the basic units of interaction with RTC SCM and contain elements which are closely related. Each component contains a single Eclipse or Visual Studio project with the same name as the Component itself [That’s our team’s convention]
• #9: Floyds not super great at remembering things And neither is his equipment (bass and amp) too reliable Luckily he, and every other band member have places on the Jazz server to save their change sets. These are called repository workspaces . [A repository workspace contains one or more components.] This repository workspace is Floyds (yours.) He uses it to back up his work, and also keep a version history of all the change stes without having to leverage a shared (code) repository But he’s even cleverer than that. When he has to change equipment he connects to Jazz and “loads” his repository workspace to get a copy. In this way you can also move from one set of equipment to another But there’s more. He can even let others see it (its on the server) All without pushing it into a shared area. Its still all Floyds
• #10: Streams and Workspaces contain a set of Components
• #11: So Floyds been working away. But now he’s got some “change sets” he want to share with his band mate, Zoot To do this he can “flow” his changes directly to him, to Zoot’s Repository Workspace Floyd can do this because Repository Workspaces have “ Flow Targets ” He flows his Change Sets from his Repository Workspace to their “ flow target” using “ deliver” and “ accept” And he can change the flow target to point wherever he likes Branches are no longer part of his vocabulary. Floyd found that the word scared people. Instead, he talks about “making and flowing changes”. Parallel jamming (development) is intrinsic in the design of Jazz. You can deliver your changes sets to wherever your flow target is pointing. You can deliver to and accept change sets from either a stream, another repository workspace, or cherry pick them from a work item or chat session.
• #12: In truth, it’s not often that Floyd directly flows his change sets directly to Zoot. What he much prefers is to lay them down, and then flow them to an area which all his band mates can see. This is what they call the “ Stream ” and its owned by the whole band. Floyd delivers his changes to it, and all the band mates can accept them from it as and when they like. Very occasionally Floyd gets really clever and does things like cherry picking change sets from an old piece of vinyl (work item) or even from a chat session. But this is pretty infrequent. Most changes go via the Stream.
• #13: Streams are important, so lets talk about them some more. While a Repository Workspace is writable only by its owner (generally). Streams are owned by a whole team. In Floyd’s case a Stream is used by the whole band to store their shared change history of all the files they’ve worked on At any given point in time, the Stream has all the files that a new band member (developer) needs to get started. It is as easy for them to join as creating themselves a personal Repository Workspace from the current state of the Stream and loading it down to their equipment
• #14: Putting it all together – a static view (Use if needed)
• #15: Everyone in the band is aware, in such a parallel, agile, Jazz world, conflicts will happen and so must also be easy to resolve In Jazz SCM “Deliver” won't create a conflict , but “Accept” (or “Resume”) can This happens on the Jazz Server , in your Repository Workspace, not on your local equipment Conflicts are stored as meta data in your Repository Workspace Conflicts can be resolved by either accepting more change-sets, discarding change sets, or merging (manual) All types of structural conflicts (e.g., moves, renames) are tracked and can be merged Floyd would be the first to admit, with someone like Animal in the band, manual merging is still painful , but not as painful as in older systems And if you structure your codebase, teams and ways of working to separate things as much as possible, reduce the shared elements, and deliver and accept frequently then there should be little problem. What do you mean you don’t do all this already?
• #17: There is one more power move which Floyd uses in order to get the most out of his use of Jazz. To remember where he or the band were with work they save an immutable state of a repository workspace or stream by creating a snapshot Floyd creates Snapshots manually when he wants They are also automatically created by and associated with Jazz builds You can promote a snapshot between streams just like you do a change set Snapshots are the baselines used to seed new streams or repository workspaces Floyd recommends you create snapshots for all important points in your development process. This means Milestone builds, releases, important builds... , other memorable moments. Etc. etc.
• #18: Make a change to a file locally When you’ve finished the changes you “check in” the group of changed files into your Repository Workspace It’s like backing them up to the server It’s still private to you But it’s also going to record the change history Files are “checked in” into a Change Set This records the before and after states of each file This includes additions, deletions, moves and renames Change Sets are owned by a Component Each Component instance has a current configuration . This is the file tree that results from applying the Change Sets in chronological order If you change files across more than one Component, Jazz will create multiple Change Sets for you For reference, give your Change Set a meaningful comment which describes it Change Sets can be discarded, suspended, resumed, or delivered They are the base currency in the RTC SCM model
• #19: When you have a collection of Change Sets you want to share with the Team They will show as “Outgoing” in your Pending Changes view Deliver them You need to associate a Work Item(s) with your Change Sets Usually a Task This ties your work into the Planning aspect of RTC As well as Requirements and Defects Which allows us to trace from top to bottom You also need to add a comment – select the change set and press “F2” Then “deliver” to the current Flow Target of your Repository Workspace
• #20: Someone else has delivered their Change Sets to the shared Stream You’ll see these as “Incoming” in your Pending Changes View They’re not yet in your Repository Workspace “ Accept” them when you’re ready for them This will add the changes to your Repository Workspace… … and load them onto your local disk
• #21: So that’s the tour. Hopefully Floyd’s explanation has given you an idea how Jazz works. Now, how does it help you be more agile? The model supports several levels of parallel development: Repository workspaces – Provides constant isolation. You don't have to make your changes visible to the team just to backup or use the repository features. Suspend and Resume – Provides task level isolation for personal work. Work Item links – Provides light weight task level isolation for personal of team work. Work on a feature, attach to a work item and discard from your workspace. You or someone else continues the work by accepting the change sets back into their repository workspace. Streams – Provides team isolation. Development Lines – Provides process isolation. Isolate work not people . Agile Development : enable quick iteration less upfront stream design simple mechanisms to collaborate within the SCM tool Benefit: teams focus on their domains and less on the SCM tool this makes it easier to incrementally evolve your development and encourages transparent planning and flexible isolation
• #22: We create a Stream for each “configuration” of your product or project that has to be built. We do one for each feature team, and another for integration between them all We also create more Streams as required when bug fixing for a previous release (from the release snapshot) When it’s been unclear which features will make it into a new release, we have even created one per feature But, because Jazz SCM is so flexible, you can start small, even with just one stream and one component Then you can grow it as your projects grows by moving files/folders into new components and creating more streams. Additionally: Each Stream has a CI Build Engine Therefore each team has a CI Build Each build references a snapshot of the artifacts that were built. Reproducing a build or patching a build is as simple as creating a new stream from the snapshot. There is no planning needed to tag or baseline, builds take care of that for us A Developer has one or more Repository Workspaces per Stream – in this way a developer can work on multiple Streams at once Developers deal mainly with accepting and delivering to their team stream Flowing changes to and from the integration streams is the responsibility of one person on each team And using Suspend and Resume, a developer can safely interleave work on new features and bug fixes
• #23: Don’t Check In frequently – your change sets contain changes for more than one thing Don’t Deliver frequently – conflicts will be more likely, and your code won’t get CI built Deliver to the wrong (non-default) Stream for your workspace – Change sets in the wrong place Use cryptic Change Set comments – when people accept and merge they read these. Make them descriptive Associate Change Sets with wrong Work Items – These group change sets logically and tie into the rest of RTC. Leverage the power! Check in temporary artefacts – don’t mess up the SCM and make checkouts longer So ask the CM team when you’re stuck We’re here to help
• #27: The Jazz SCM is entirely Change Set based. There is no file level branching or tagging. Focuses on user level simplification with the added power of parallel development. Conscious effort to never use the word branch in the UI. People are afraid of branches, but want isolation and the features they provide So… Modern SCM model : Change sets, streams, components, GDD support, and simple parallel development. Benefit: Makes it a lot easier to collaborate in an SCM tool, exchange changes, suspend, resume, cherry-pick changes Agile Development : enable quick iteration, less upfront stream design, simple mechanisms to collaborate within the SCM tool. Benefit: Allows team to focus on their domains and less about the SCM tool. Make it easier to incrementally evolve your products.