When the Git Tool Stack Falls Over
Over the last three decades, employment in the tech industry has grown more than four times, just in the United States. And that trajectory is not slowing down. In the middle of all this growth, the open source community sprung to life, and Git was born. Because it’s free, Git benefitted from the organic growth of the software business.
Perforce has a unique perspective on the growth of the software industry and the popularity of Git. As our user base grows, we continue to see the importance of scalability and performance in a version control tool in order for our customers to stay competitive.
The purpose of this blog is to give you a perspective on the Git challenges that many believe have been solved. Git is ubiquitous. But that doesn’t mean it’s the best choice for everyone. In an environment where things are growing quickly, new challenges arise all the time.
Let’s look at the circumstances that make the Git tool stack fall over, and what to do about it when that happens.
Using Git When You Have Large Files
Increasingly, projects contain both code and non-code assets. This is true of games, but projects that used to be very small, like mobile apps, now include videos and other objects that can be cumbersome to handle during development.
The community has a solution for large files – Git LFS. Our clients tell us that it works, but they also say that using Git LFS isn’t manageable.
LFS is an extension that must be installed on every workstation and/or repo. Once installed, there’s no visibility and little control. Problems can occur when a developer doesn’t have the extension. And there are often added steps that need to be maintained with build runners, such as Jenkins. This adds time-consuming complexity at scale.
Helix Core’s ability to handle large files is one of the things Perforce is known for. It’s a native capability, not an add-on, and it’s bulletproof.
Using Git With a Global Team
If you’re a startup game studio with three people in “the garage,” or even 20 developers scattered around the country working virtually, Git is probably fine. (Other than the way it handles/doesn’t handle large files). But if you wake up one day and have offices on three continents, with 20-50 people in each one, then you’re probably having issues organizing repos with Git, not to mention challenges managing disk space.
Why doesn’t this work? People usually pull entire repos onto their workstations or to server volumes. This duplication adds up. Cloning and copying take a lot of time too, and it negatively affects developer productivity.
Helix Core handles this differently – with replication. Perforce’s federated architecture, also known as “Commit/Edge,” lets each office have its own server. That server can be Linux, Macintosh, or PC.
With the federated architecture, assets are constantly updated, so they’re available when designers and developers need them.
Any designer or developer can check out and lock one file at a time, which many find magical. This means she’s the only person in the world who can work on that file, until she’s done.
Compliance, Regulation, Traceability, and Security – Does Git Pass the Bar?
Git is best-suited for web development. It doesn’t have a high focus on compliance, highly regulated industries, traceability, or security. And, frankly, neither do the developers who are tooling around Git.
Git comes from a simpler time, when the population of the web was primarily care bears, unicorns, and some kittens.
If your company needs accelerated product delivery in financial services, medical and life science, automotive, aerospace, and defense, you need a system that gives you ultimate control with traceability over quality and security. Systems are mission critical and safety critical.
With Helix Core, you can track and trace every change, which lets you maintain that traceability for the entire lifecycle of the product, end to end. With Helix ALM, you can also link the changes to requirements, test cases, and all dependencies – all in a robust traceability matrix.
Git Repos Can’t Deliver Assets Fast Enough for Continuous Integration
One of the biggest challenges we’ve heard from clients is that their Git servers can’t keep up with the demands of numerous developers working simultaneously in a Continuous Integration (CI) workflow.
Cloning and copying slows things down. You can’t solve this problem by throwing more CPUs and memory at it. Once the code is there, the build can generally happen quickly.
Helix Core executes CI much faster – as much as 80 percent faster – with multi-threading and parallel syncs between the repo and the workspace being used by the build runner.
Helix Core also supports artifacts and other binaries to speed performance. Often, a separate Helix Edge server is configured and dedicated to builds, which results in more performance improvement.
Did I mention that you can add build servers to your Helix Core network for free? It's true. With our federated architecture, it's free to add Edge, replica, and Helix Proxy Servers (P4P).
By the Way, Perforce Has Git Too
You may have noticed that most of the challenges we discussed have dimensions of scale. The theme is clear: Git doesn’t scale well.
Over the last few years, we’ve built out our core VCS offerings by adding Git tools. And the biggest area we addressed is using Git at scale.
Helix4Git and Helix TeamHub allow Git teams to leverage the speed and performance of Helix Core. It’s the first truly federated, scalable Git solution for enterprise teams. You get:
- Faster CI/CD build performance.
- Support for multi-repo projects, artifact repositories, and even a Docker container registry.
- The ability to gradually add nodes.
- Replication and guaranteed up-to-date content with no lag, instead of copying.
And you get that with a high-performance, Git server that is completely compatible with all your tools.