Branching Out: How To Automate Your Development Process

Brad Hart, VCS Chief Technology Officer
Brent Schiestl, Senior Product Manager

perforce.com2 | Perforce © Perforce Software, Inc.
Confidentiality Statement
The information contained in this document is strictly confidential, privileged, and
only for the information of the intended recipient. The information contained in this
document may not be otherwise used, disclosed, copied, altered, or distributed
without the prior written consent of Perforce Software, Inc.

Your Presenters
Brad Hart
VCS Chief Technology Officer
Brent Schiestl
Sr. Product Management

How to Automate Your Development Process
1
2
3
4
Challenges Managing Branches
What Is Streams?
Streams Use Cases
Questions

Branching and Merging at Scale
• All development processes follow one or more “patterns.”
• Parallel development supports:
• Multiple teams, multiple releases, lots of users.
• Feature based development.
• Some have names, like GitFlow.
• All development patterns are managed with branching, merging, and tagging.
• For many teams, it is NOT automated. Challenges include:
• Prone to errors.
• Hard to learn/ remember. Often documented on a whiteboard!
• Many companies write scripts to manage.
• Costly to maintain.
• These issues are amplified as teams scale.
• Merge conflicts, failed builds, drawn out releases.

Design and Automate Development
• Streams is how teams branch and merge in
Helix Core — version control by Perforce.
• Streams help you:
• Automate YOUR desired development process.
• Track branch to branch relationships.
• Visualize development in the Stream Graph.
• Minimize merge conflicts.
• Streamline your build process.
• No more scripts to write, nothing to
remember, less ERRORS!
• Streams supports complex development
processes while reducing bottlenecks and
accelerating teams.

When to Use Streams? Do You Have….
Component Based
Development
• How many components and
microservices do you have?
How many products use these?
• How many repositories do you
need to manage?
• Are your components shared
across multiple products?
• How do you bring these
components together?
Development Pipeline/Maturity
Model/Shift Left
• Is your organization currently
looking to shift-left?
• Are you having quality issues in
production?
• Have you had regressions make
it into production?
• When are bugs typically found
in the development process?
Multiple Teams, Releases, and
Variants
• How large are your teams?
• How many teams work on a
given product?
• How are your teams defined?
• Do you have to support
multiple slightly different
versions of the same product?
• How do you merge changes
across versions?
Streams can help you automate more and solve challenges, no matter your development method.

• Component Based Development (CBD) includes:
• Shared code.
• Common code.
• Microservices
• Producer/Consumer.
• CBD creates building blocks.
• Each “block” is worked on independently.
• “Blocks” are put together to create larger blocks.
• Larger groups of blocks are put together to create systems.
• Think of an automotive assembly line…
Component Based Development
+ +
=
+ +
=

• CBD can have 100s to 10,000s of components.
• Difficult to keep track of all the dependencies.
• Late integration testing can lead to massive schedule delays and
defects.
• Propagating component defect fixes to all larger building blocks is
a monumental task and very often manual.
• You can create heavy-weight scripted layers on top of the VCS.
These solutions are:
• Painful to update.
• Costly to maintain.
• Not flexible.
• Quickly out-of-date.
Component Based Development Challenges

• With Streams, all components are managed
independently and graphically.
• New versions of a component can be easily
tested just like code changes!
• Configurations are fully versioned giving
ultimate traceability.
• Simplifies developer experience.
• No need for external scripting for fewer:
• Mistakes.
• Regressions.
• Incorrect product configs.
• Delayed releases.
Component Based Development + Streams
Product is built from desired
version of each component.

• Enterprises looking to modernize need a way to:
• Maintain legacy code.
• Improve performance and quality.
• Break up monolith structures.
• Integrate with CI/CD tool.
• Helix Core mitigates organizational risk, giving you time to slowly
move to CBD.
• Migrate your legacy monolith and implement CBD for new projects.
Streams Supports Monolith >> CBD
Existing Monolith à
Easiest, risk free path to components/microservices
Immediate performance and velocity improvement
STREAMS

Development Pipeline/Maturity Model/Shift Left

• The later a defect is found, the more expensive it is to fix.
• Rework due to late stage defect detection chokes velocity.
• Mixing immature code with mature code creates havoc .
• Teams often need to send the “everyone stop checking in code so we can
get a clean build to QA” email.
• Shift-Left = Finding defects early in CI and testing.
• Keeping immature code separate from mature code streamlines the
development pipeline and keeps it running
• Ex: A bad checkin from a developer won’t break the build QA is testing.
Development Pipeline/Maturity Model/Shift Left

Development Pipeline Challenges
New Functionality
(Innovation)
PLAN CODE BUILD TEST RUN
bugs
Users
User experience
Bug fix backlog slows
down teams.
Bug fixes – unplanned work
(found in QA or Production)
bottlenecks
$$$$
$$$
$
Focus on quality too late in SDLC
impacts cost and velocity.
Gaps in digital test coverage
impacts user experience, brand, and adoption.

P1P1 P2 P1 P2 P3+ + +
Unit/Validate/Debug
CI - Smoke Scheduled Nightly NF UAT
Unit/Validate/Debug
Unit/Validate/Debug Production
Trigger
Feedback
Time
Pre-commit
Manually / On demand
Few minutes
Per-commit
Automatically
< 5-10 minutes
Every 3-4 Hours
Automatically
Nightly
Automatically
3-4 Hours 1 Day
24/7
Automatically
< 5 minutes
Nightly
Automatically
1 Day
Security
Performance
Devs
Test
Coverage

Shift Left +
Streams
Dev Workspace
Code is fully tested before a person
reviews the changes.
Dev CI stream provides fast
feedback to the developer.
Test Streams provide
isolated environments for
automated testing, which
won’t be polluted with bad
checkins.
Less Stable
• With Streams, your teams can:
• Easily separate immature code
from mature code.
• Get faster feedback.
• Find defects earlier to help
avoid costly development
delays.
More Stable

Multiple Teams, Releases, and Variants

• Companies with large, complex products often have:
• Multiple component teams.
• Feature teams.
• Front end/backend/API/database teams.
• Organizing and orchestrating the work of multiple teams, whose changes are interdependent is difficult.
• Often there is limited visibility into what everyone is working on and how it is connected.
• Teams defer integration and integration testing as it is too difficult.
• Waiting until the end causes delays in production, massive rework, and quality issues.
• Much like “merge early, merge often” is a best practices within a team, “integrate early, integrate often”
is a best practice across teams.
• This is very difficult unless you have the right VCS and process.
Multiple Teams

Challenges for Multiple Teams
Backend API
E2E / Integration Pre-prod Production
Team A
Team B
Integration
Integration
Integration
• Late integration can cause ”Release Tail.”
• Need to test pre & post integration to quickly
identify of root cause of failure.
• Without a single unified platform, your
feedback loop can loose speed.

Multiple Teams + Streams
API Teams Grouped Together
• Easy to see how teams relate
to one another.
• Encourages integration
EARLY.
• Automates the separation
and then integration of
multiple teams.
• Easily see when changes are
ready to integrate from one
team to another.

• If you are supporting multiple product releases, you have a lot to support.
• This means bug fixes across multiple versions.
• For example, (4 major releases per year + 8 minor releases per year) * 3 years support
= 36 releases to support!
• Patching defects across multiple releases is very difficult.
• Which releases do you need to patch?
• What branch(es) do you need to patch into?
• How do you avoid regressions in future releases?
• Patching is often done manually due to VCS limitations.
• ZERO traceability .
• Highly resource intensive.
Parallel Releases

• Streams allows you to visualize
all your releases and see how
they are connected.
• More easily propagate bug
fixes.
• Maintain releases with higher
quality.
Parallel Releases + Streams

Multiple Variants
• Companies often need to produce slightly different versions of a given product.
• Most of the code is the same.
• Each variant differs.
• Fix or new feature code must be propagated across variant products.
• This could involve hundreds of variants.
• They must be maintained and tested each time a change is made to the base code.
• Propagating changes across variants has the same problems as supporting multiple parallel releases.
• Hard to determine where the changes need to go.
• Manual process to perform and verify the merge.
• Managing multiple variants can be costly and the stakes are extremely high.
16 GB 32 GB 64 GB 128 GB 256 GB

Multiple Variants + Streams
Stream contains
base/common code for
all flash drives.
Stream inherits base/common code from
“flash” stream. It contains all the specific
code needed for the 128GB version.
With Streams, you always know where
code should flow. It is easy to see what
releases need changes and updates!

• AUTOMATE any development process.
• Implement FLEXIBLE workflows.
• Maintain CONTROL.
• SIMPLIFY complex environments.
Start increasing your teams’ velocity and improving code quality.
With Streams, You Can….

Branching Out: How To Automate Your Development Process

Recommended

More Related Content

What's hot (20)

Similar to Branching Out: How To Automate Your Development Process (20)

More from Perforce (20)

Recently uploaded (20)

Branching Out: How To Automate Your Development Process