Git is increasingly a part of the enterprise because developers love its speed and flexibility. Yet Git also poses a variety of challenges for non-developers: security, scalability, visibility, and more. See live demonstrations of how GitSwarm, the complete Git management solution, addresses and serves the needs of every stakeholder through the power of Helix.
Software Project Health Check: Best Practices and Techniques for Your Product...
Making Git Work for the Enterprise Through the Power of Perforce Helix
1. Making Git Work for the
Enterprise Through the
Power of Perforce Helix
John Williston, Ph.D. Product Marketing Manager
Geoff Nichol, Principal Architect
2. 2
Git is a Very Popular 10-Year-Old
— 2015 Stack Overflow
Developer Survey
69.3%
of developers use Git
2005 2015
3. 3
But It Poses Challenges to the Enterprise
Maximum practical repository size
Leading to Git sprawl (lots of repos)
Too complex for some contributors
Raises security concerns
Weak visibility across the entire pipeline
DevOps challenges for continuous delivery
Destructible history can be a problem
4. 4
Inefficient Product Delivery
Poor visibility between
teams introduce friction
and design errors
Poor component reuse
results in higher
production cost
More delays, less efficient
product delivery
Less secure
Increased risk of
quality issues
DevOps
5. 5
Recent Gartner market guide
“
“
Enterprise-grade management of Git
that offers important aspects of a DVCS —
good merging, the ability to work offline
and good collaboration — along with the
security and central repository of a CVCS,
will resolve most remaining concerns
about the use of the DVCS model.
— Gartner, Inc. Market Guide for Software
Change and Configuration Management
6. 6
Hybrid Workflows
• Distributed & Centralized Version control,
code reviews, simple file sharing
• Happy developers & contributors
Every File
• Efficiently handles large, often binary, data
DevOps Stay Happy & Productive
• A mainline source for all builds even with
distributed development
All IP Safe & Secure
• Granular permissions, theft risk monitoring
Perforce Helix
CONTRIBUTORS
CONSUMERS
7. 7
More performance
More uptime
More control
Better coordination
Binaries
Large files
Protect IP
Regulations/audit
More code
More frequently
More freedom
More flexibility
All text
Small files
Code anywhere
Local repos
Perforce Helix
Serves developers Serves operations
Coordinate Development & Operations at Scale
8. 8
GitSwarm: Integrated Git Management
Based on GitLab CE
Self-service repos
Merge requests
Permissions
Issue tracking, etc.
9. 9
Mirrored to the Helix Versioning Engine
Automatic bidirectional mirroring with Helix servers
Helix enforces security, down to the file level if needed
Immutable content for audit trails, regulated industries, etc.
Support for Git LFS that works for DevOps
10. 10
Work Locally, Scale Globally
Distributed environment
for developers
Git experience and workflow
equivalent to well known tools
Single source of truth
Perforce reliability and stability
protecting your assets
HelixGitSwarm
11. 11
Distributed Team Support
Each developer team
working within its own
GitSwarm ecosystem
Each team has controlled
access to IP managed
within Helix core
Team can access only what
they need to do their job
12. 12
Narrow Cloning
Narrow cloning with Git
Git-sized slices of a huge Helix
monorepo
Remap content as needed
Optional shallow-cloning
Mirror content from local Git
repo to the master monorepo
Art
Code
Core
iOS
Win
Tests
Shared
Helix Code
Core
iOS
Tests
Jill’s
Git repo
Code
Core
Win
Tests
John’s
Git repo
13. 13
GitSwarm Enterprise Edition
Extends LDAP support
Share projects between groups
Git hooks
Two factor authentication (LDAP)
Jira integration
Import from GitHub Enterprise
Available as an add-on option
Git use has exploded among developers since its introduction into the industry
The reason is that developers like a lot of things about Git:
Fast performance running commands against the local system rather than client/server round-trip
Lightweight in-place branching helps in a number of ways:
Makes it easy to deal with multiple concurrent tasks
Easy to make a new branch for research purposes and throw away if it doesn’t pan out
Easy to make a new branch when interrupted with a bug fix or something else
Helps separate my work from everyone else’s until I’m ready to share it
Mutable history means I can commit as often as I want yet ultimate share only a clear, coherent line of development
Large ecosystem of tools and easy customization of commands via aliases
It’s adoption is somewhat less in the enterprise for reasons we’ll see
The maximum practical repo size is generally accepted as being 1 – 2 GB
Some folks will object that they work with much larger repos, but it doesn’t generally work well
It’s that limit that leads to “Git sprawl”, breaking content into LOTS (dozens, hundreds, even thousands) of repos to keep them small enough
Git’s command set confuses even programmers; not well suited for artists, animators, documentation, etc.
Git can authenticate contributors using signed keys, but it has ZERO authorization controls; i.e., no controlling who can do what
Visibility is basically non-existent without third-party tools like GitHub, GitLab, etc.
DevOps challenges are many and varied:
Stitching together content from all those many repos
Component versioning when doing CBD
So many repos means a lot of clones for CI/CT/CD, which topples many servers
Most third-party Git tools are single-server topology
Automating synchronization of code across multiple working groups can be painful
Git wasn’t designed with high concurrency in mind
Potential destruction of shared history through rebasing renders it unsuitable for some industries
Because Git isn’t suitable for everyone and every task it leads to silos
This complicates development and leads to inefficient product delivery
Separates teams and divides rather than unites
Makes it hard to reuse content, especially across teams
And it’s not just us saying this. In a recent report, available free of charge from Perforce, Gartner identified both the benefits of DVCS for developer desktops and the need for enterprise management usually provided by centralized VCS.
It’s worth noting that Perforce Helix was one of only two commercial products called out as supporting this hybrid model.
In contrast to what’s already been said:
Helix covers all the workflows and needs across an enterprise from developers to DevOps while protecting valuable intellectual property (IP)
Developers get to use tools they like, even Git and its complete ecosystem if they prefer, which keeps them happy
Helix offers clients suitable for non-developers
And because everything can be in a “single source of truth”, even one big monorepo if desired, DevOps is happy
Helix closes the security holes and even detects threats before IP walks out the door
And provides visibility into the whole pipeline
Perforce Helix was designed to solve these problems.
As the underlying collaboration platform across the organization it provides the shared hub for developers and operations to address the issues raised earlier.
GitSwarm is the new Helix component that provides all-in-one Git management
It’s based on GitLab, so it has all the great features developers expect:
Easy repo management through a strong one-to-one project-to-repo metaphor
Collaborative workflow through per-task feature branching and merge requests
Flexible permissions through groups and users with a variety of roles
Lightweight ALM features like milestone and issue tracking
Even a wiki to store helpful links, documentation, etc.
So why GitSwarm if it’s built on GitLab? Because our “secret sauce” is automatic, bidirectional mirroring with Helix
This means Helix can enforce finely grained security right down to the file level if needed
But without the possibility of destruction of shared history in a company-ruining mistake
And upcoming support for Git LFS that will work for DevOps; when it’s available ours will be the world’s most capable Git LFS server
The result of this is that developers who prefer Git can use it directly with GitSwarm
They get everything they like and can use all their familiar tools and workflows
Yet Helix provides the underlying single source of truth with which all the rest of the Helix platform interacts
Multiple GitSwarm servers make it possible to divide projects by teams for a variety of reasons
Give distributed teams a GitSwarm server local to them
Segregate content by IP security restrictions
Helix is the only system that supports narrow cloning, letting you clone just the pieces of a huge monorepo that you need
It works best with our native DVCS features
But through GitSwarm we’ve brought narrow cloning to Git, something Git users have long wanted
Specific details if needed:
Git repos are defined under the hood by Git Fusion
So you can use all the usual repo-remapping features:
Compose a new repo from lots of bits from different places
Rename and remap files and folders as needed
GitSwarm can then import and mirror from any of those repos
So your developers using Git can effectively filter what they need
Caveat: GitSwarm doesn’t have a UI for handling this yet, but it’s important on the GitSwarm roadmap
For some enterprise customers, they may be interested in the optional add-on: GitSwarm Enterprise Edition. This adds more detailed control over LDAP permissions, richer integration with Jira and the ability to import GitHub Enterprise projects.