9.16.2013 Enlightenment Series - Managing parallel development with RTC: A strategy for software integration and release

®

IBM Software Group

© 2009 IBM Corporation

Umang Shah ([email protected])

Open Group Master Certified IT Specialist

IBM Rational Software

Parallel Development using RTC

IBM Rational software

Agenda

Jazz Source Control

Parallel Development

Streams

Flow Targets

Example of Project Configuration

Security – Access Control at Stream Level

2


Jazz source control: Key elements and capabilities

Elements Change sets

Streams

Components

Capabilities Task-based development

Refactoring (move and rename)

Parallel development

Lifecycle tool integrations

Process integration

Dashboard contribution

Event notification


Change sets

A change set is a repository object that collects a related group of changes to files, folders, and components.

The source control storage model is based entirely on change sets, providing “atomic” changes to a set of related files.

Change sets can be shared (through work items), suspended, discarded, and reverted.


Change sets

The system tracks the changes that you make in the context of a work item.

The changes are collected into a change set and associated with the work item.

Change sets are applied to a flow target in a single atomic operation:

Outgoing change sets are typically delivered from a repository workspace to a stream.

Incoming change sets are accepted into a workspace from a stream.

Accept

Streams

Local Sandboxes

CheckIn

Deliver Accept

Repository Workspaces

= a change set


Creating and managing change sets

Change sets are compiled automatically.

Work on one work item at a time.

If you need to switch contexts and work on another work item, complete one of these procedures:

Keep active work items in different local workspaces so that each work item has an isolated development sandbox.

Suspend work on a work item, which stores that work temporarily. Your Local

Workspaces

Deliver

SuspendWork

Repository Workspaces

Streams


Typical Journey For A Change set

Local Sandbox

2b.Change set

4. Deliver

1. Change

3. Complete (usually combined with deliver)

2a. Check-in

7Module 4 - Performin

g and Sharing

Your Work


Streams

Teams or projects own a set of streams that provide a simple mechanism for sharing change sets between team members.

Streams can be created for ad hoc collaborations, and streams can be created from builds to reproduce released products.

Streams provide an efficient scaling mechanism where teams of teams can be isolated and flow their changes into stream hierarchies as integration is required.


Components

Components provide a composition mechanism to organize work within the same repository File-level changes are grouped into change sets.

Change sets belong to a specific component.

Related components are grouped into streams.

Stream

ComponentComponentComponent

Change set Change set Change set


Parallel development Repository workspaces

Provide constant isolation and stored in Jazz repository.

The workspace contains private copies of files and folders that a developer is working with.

Suspend and resume functions

Provide task-level isolation for personal work.

Streams

Provide isolation at various levels including team, feature, integration, release, and maintenance as desired

Locks

Provide selective isolation. By locking files in the stream, users can avoid merging.

Timelines

Provide process isolation.


Using workspaces in a team environment

Load

Copies the configuration of files that are specified for the repository workspace to the local sandbox

Check-in

Copies changed files from the local sandbox to the repository workspace

Deliver

Copies the changes from the repository workspace to the stream

Accept

Copies others’ changes to the stream into the repository workspace and the local sandbox

Load

Streams

Local sandboxes

Checkin

Deliver Accept

Accept

Repository workspaces


Change flow for small or medium teams

The flow target of a workspace is the repository object (workspace or stream) where changes from the workspace are delivered by default.

For most small or medium teams, the flow target of a developer’s repository workspace is the top-level stream.

The stream represents the team’s integration area.

Team

Team members

Deliver Accept

Accept

LoadCheck-in


Change flow for large teams

A team hierarchy can be built by using shared repository workspaces and streams at the intermediate levels.

Team of teams

Team

Team members

Deliver

Deliver Deliver

Accept

AcceptAccept

Accept Accept

Load LoadCheck-inCheck-in


Changing flow targets


Changing flow targets

Multiple flow targets can be defined, but only one

can be “current.”

Identify the default flow target.

Set the current flow target.


Flow diagrams

Flow diagrams provide a graphical representation of change flow in a project, identifying the flow target for each repository workspace or stream.


Flow diagrams

Example: A project with three components and three corresponding streams


Example: Feature Streams

Feature Stream 1 is created at #1

Feature Stream is created at #2

Integration from both Feature Streams occurs at #3 and #4

A Baseline is created in Main Development Stream at #5

Build and Release is created from Baseline #5

After final deliveries from Feature Streams, it should be removed

18


Example: Release and Integration Streams

A baseline is shown at #3 in the Main Development stream, which is delivered to the Integration stream at #4.

The integrated application can then be tested before a release from baseline #5 in the Integration and Release stream.

Further development work then takes place on the Feature streams up to points #6 and #7, which are then delivered to the Main Development stream at #8.

Feature stream 2 is then closed and removed.

Further work takes place on the Main Development stream up to point #9, where a new baseline is created and delivered to the Integration and Release stream.

A new baseline is then created on the shared Integration and Release stream at #10 to manage the release to production. 19


Example: Splitting Integration and Release Stream

Splitting Release Stream allows the team to increase security of release stream to control which roles can deliver to Release Stream

20

Release Stream

Emergency Fix Stream

A new Release Stream created at #5, and a Release using Baseline #6

A new Emergency Fix Stream Created at #6 and Emergency Fix Delivered to Release Stream at #8

A delivery of code from Emergency Fix Stream to Main Development Stream at #11

The integrated application can then be tested before a release from baseline #5 in the Integration and Release stream.

Feature Streams are delivered to Main Development at #9 and #10

Interim Baseline is created on Main Development line at #12 and delivered to Integration Stream at #13

A new Release stream can be created for next Release


Release, Integration and Emergency Fix Stream (Cont)Flow Diagram

21


Example: 2nd Release and Emergency Fix Streams

22


Example: Continued Development Activity

Feature Stream 3 is created at #12

Remove the stream not needed for simplicity

23


Stream Activity over Project lifetime

24


Controlling Deliveries to Streams

25


Controlling Deliveries to Streams

26


Modify Stream Operation pre-conditions Prevent adding a component to a stream:This precondition prevents users from adding a

component to a stream if the component owner is different from the stream owner.

Prevent adding a user-owned component:This precondition prevents users from adding a component to a stream if the component is owned by a user rather than by a team or project.

Restrict stream visibility from being set to "public":This precondition prevents users from changing the visibility of a stream from "private" (team or user) to "public" (project).

27

Technology

9.16.2013 Enlightenment Series - Managing parallel development with RTC: A strategy for software integration and release