Making Git Work for the Enterprise Through the Power of Perforce Helix

Editor's Notes

• #3: 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
• #4: 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
• #5: 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
• #6: 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.
• #7: 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
• #8: 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.
• #9: 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.
• #10: 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
• #11: 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
• #12: 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
• #13: 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
• #14: 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.