streams in parallel development by sven erik knop
TRANSCRIPT
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