18. Opportunities for DVCS in the Enterprise
• Fast local workflows
• Independent contributors/teams
• Pool of potential recruits/strong community
21. Challenges for DVCS in the Enterprise
• Not suitable for all content
• No visibility
• Poor security
• IP loss risk
• Not built for enterprise projects
• Lack of ownership & roadmap
24. Helix Distributed
•Your personal Helix server, running locally
•Streams workflow
•Consistent command line
•Handle any file type/size
•Honours protections
•Narrow clones
•Share with the team when ready
•Server to Server sharing
25. New DVCS commands
•init - Create a new personal server
•clone - Clone a new personal server from a shared server
•remote - Define a connection to a shared server
•fetch - Copy files from a shared server to a personal server
•push - Copy files from a personal server to a shared server
•switch - Switch to a new stream, optionally creating it
•unsubmit - Unsubmit a change, leaving the work in a shelf
•resubmit - Resubmit unsubmitted changes
26. No need to split projects into multiple repos
Select relevant content, clone, and work offline
Better performance with large clones
Helix Distributed for Server/Server
28. Helix GitSwarm
Distributed environment for developers
Git experience and workflow equivalent
to well known tools
Configurable sync
Single source of truth
Perforce reliability and stability
protecting your assets
HelixGitSwarm
30. Helix GitSwarm
•Rich, browser-based environment for managing Git
repositories, workflow & tooling
•Automatic mirroring with the shared Helix server
•Helix enforces security – traditional Perforce protection down
to the file level, maintains immutable audit trail
•Work with narrow clones from the Helix depot
41. GitSwarm EE
• Available as an add-on option
• Extends LDAP support
• Share projects between groups
• Jira integration
• Import from GitHub Enterprise
43. Git Fusion?
•At the heart of GitSwarm integration
•Still used for standalone Git – Helix integration
•Significant performance improvements
• > 1000x in some cases
46. Shared enterprise master repository/depot
GitSwarm
Git Fusion
Interact with
Helix via Git
Tower*
Browser-based
code review,
collaborations,
pull requests,
work items, wiki
Cmdline, IDE &
other git clients
3rd Party
desktop client
Swarm
Browser-based
code
collaboration
CI integration
Helix Distributed
Desktop client
P4, P4V, API
Cmd line,
desktop & IDE
clients
Cmd line, local
Helix repos
Interact directly
with Helix
Jenkins/
Puppet/Chef/…
High Performance
CI/CD
Enterprise Repo
ID & Access Mgmt
IP Threat Detection*
Immutable audit trails
Federation, HA/DR
deployments
47. Gartner
Centralized management practices, evolved from centalized
VCS … needed to match freedom of DVCS with discipline
required by large-scale enterprise deployments.
Although DVCS alone may suffice on the desktop, additional
central management needed for good release discipline
Let’s start with some numbers a quick quiz. Who knows what these numbers mean?
Gartner’s estimate of number of developers using Git or Mercurial. Source: market Guide for SCCM Aug 2015
https://android.googlesource.com
Admittedly, not all users will need all repos, but just selecting the right ones could be a challenge
Years since publication of Git – recent birthday events
First Generation: Local, server-based Version Management
Second Generation: Client-server, centralized. Local working copies, shared master repository. Earliest versions required locking files before doing work. Later versions made this optional with reconciliation of “offline” work
Third Generation: Distributed, peer-to-peer versioning. Everyone has a copy of all assets (regardless of size). Everyone can share with everyone else – when they want to.
Effectively, all the recommended SCM worflows are centralized! The pro-DVCS and anti-CVCS has been very badly promoted.
Sure there have been some inhibitors in the CVCS workflows in the past – for some users, e.g. coders, locking files before edit gets in the way. However other users much prefer locking as a way to know who’s working on what and preventing clashes or loss of changes. And even for those that see locking as an issue – the more forward looking tools, like Perforce, have long provided alternatives to locking so this was always a false concern.
But the problem with this pattern is that it depends on Git being on the server. Even if using a hosted service like GitHub, you’re still using Git with all the issues that brings – limits on file sizes, poor security, hard to manage large projects, …. The reason Android needs over 800 repos is because Git has problems with any reasonably complex projects.
Until GitHub implemented this style of working, Git was very much a niche tool. It was clear that this centralization was needed.
Fourth Generation: Hybrid Version Management
This session is not intended to be totally negative about Git and DVCS. There are many good points about DVCS and the way that it can enable rapid development.
One of the strengths, undoubtedly, is that Git, for all its issues has become the lingua franca. Rightly or wrongly, most graduates doing any kind of coding have some experience of Git.
There are always plenty of resources available to help when you want to know how to do something in Git.
From reddit: www.reddit.com%2Fr%2FProgrammerHumor%2Fcomments%2F2rrmg9%2Fsimple_git_workflow%2F&psig=AFQjCNGeYQ-qDRstcyRkR71HSeY92TX5vQ&ust=1441882483738220
Anyone who’s used Git has probably, more than once, searched for help. Usually we take a command that looks about right and run it – and then find it’s not quite what we wanted there’s a whole new world of pain to clean up the mess!
It’s kind of interesting that one of the metrics often quoted for the popularity of a language or development tool is the number of searches on Google. I always thought that was a strange metric – surely that tells you how many times people needed help not how good something was working. As an example, I did a search for “Git Tutorial” – over 27.5 million hits. Doesn’t that mean that a lot of people need tutorials and none of them are so good that you don’t have to write just one more “tutorial to bind them all|?
The rate of change doesn’t seem to be slowing. OK, growth may be because there are more users than ever but shouldn’t Git be getting easier to use?
So, it’s not all rosy in the Git garden. The limitations with Git are pretty well known and understood. What’s more surprising is how much pain users are willing to endure. The 800+ android repos aren’t that way because that’s the optimal way to arrange your work – it’s that way because of the difficulties of managing a large code base with Git.
Source reddit: www
The arrival of various artefact repositories didn’t happen because they were a thing of beauty that users desired – they were created to get around the limitations in the version management tools being used. Predominantly, Git.
After 10 years of development, surely these fundamental issues should have been fixed. Sadly not. With no clear owner and leadership, it’s not clear when they will be. There is some work to address some of the issues – for example there are a few different suggestions for how to handle the large file issues including Git-annex and Git LFS. I haven’t seen anything addressing the issues of security in any meaningful way.
I don’t think it’s unfair to say that, after 10 years, there should be a better solution for DVCS. It doesn’t look like it’s going to come from the Git community – so Perforce are taking the lead with the introduction of
.reddit.com%2Fr%2FProgrammerHumor%2Fcomments%2F3czy0l%2Fgit_commit_m_fixed_interface_issues%2F&psig=AFQjCNGeYQ-qDRstcyRkR71HSeY92TX5vQ&ust=1441882483738220
There are two parts to solving this problem of enabling DVCS working while still providing enterprise-class management.
Providing a way to bring the work of Git users into the fold – something that has become known as “Git Management Tools” – although that name is both more and less than what that name might suggest. Perforce has introduced its own such tool which provides unique capabilities – Helix GitSwarm. I’ll go into more detail in a minute
Building a better DVCS. After all Perforce has nearly 20 years experience in fast, scalable, secure version management – who better to provide such a solution? We talk about Helix in “Local Mode” or for those of you who have already started using Helix 15.1, you may have already seen some of the DVCS features now available. More on this in a minute as well.
Unsubmit/resubmit – excellent workflow for ensuring your local base is up to date before merging your changes and then sending to the server.