Streams in Parallel Development

Sven Erik Knop

Why use Streams?

•Your developers want

• A simple way to join a project

• Easy and fast branching and merging

• Work independently but be aware of other changes

•Project Managers and DevOps team want

• Overview of changes that need to be propagated

• Simple way to filter files for build and deploy

What are Streams?

•Simplified client workspace management

•Simplified branching and merging

•Simplified build and delivery

•Enable Component Based Development

Client Workspace management

//project/

rel1.0/...

rel1.1/...

share ...

workspace my_ws

client: my_ws

view:

//project/main/... //my_ws/... main/...

Streams provide the template for the client workspace view mapping

stream depot stream

Branching and Merging

•Different types of streams

•Streams have a parent

•Fast switching between streams

•Relationship defines how changes are propagated

• Follows the mainline model

Mainline model

•Merge down

• From stable to less stable

•Copy up

• From less stable to stable

Task streams

•Task streams are temporary streams

• Can be unloaded and/or deleted

• Retrospective sparse branching

•Useful for short-term tasks

•No integrations between tasks streams!

•Alternative: shelves and reviews

Virtual streams

module_2

main

Type: virtual Paths: share module_2/...

• Filter stream content • Rename files and directories • Submits go straight to backing stream

Import and Import+

•Import streams and classical depot paths into your stream

•Imports are read-only

• Can be fixed at change or dynamic label

•Import+ for writable imports

import mod1/... //stream/comp1/...

import+ mod2/... //stream/comp2/...

import mod3/... //depot/3rd_party/comp3/...@3141592

Build and release

•Concentrate only on relevant files

•Import supporting files such as libraries or artefacts

•Virtual streams are the templates

Component Based Development (CBD)

•Large systems, small pieces

•Tames complexity

•Faster to market

•Reuse for greater ROI

Stream support for CBD

•Each component has its own mainline

• Potentially separate release streams

•Components are imported at

• Release stream

• Mainline stream at label or change

• Mainline or even development line (during early stages)

•Stream definition becomes configuration

Stream Depots and StreamDepth

•Streams live in dedicated streams depots

•Stream depots have adjustable streams depth

• StreamDepth: //stream/1/2/3

• StreamDepth: //stream/project/component/codeline

•P4V support in P4V 2016.1

• ftp://ftp.perforce.com/perforce/snapshot/p4v

Edit, Resolve, Revert and Commit

•p4 stream edit

•p4 stream revert

•p4 stream resolve

•Isolates changes to a stream until submitted

Best practices for parallel development

•Follow the mainline model

•Break up large projects using virtual streams

•Use separate mainlines for components

•Import components at release, main or even change

•Last not least ... version everything

Conclusion

•Perforce Streams were designed around the mainline model

•Natural choice for

• New adopters of Perforce Helix

• New projects

• Component Based Development

• Build and release managers

Sven Erik Knop

@p4sven

sknop@perforce.com

Q&A