Git Enterprise Requirements
March 18th, 2009If you’re an individual developer or a small team, I wouldn’t think twice before recommending using Git.
But beyond that I have some reservations. At least for where Git is right now.
That hesitation is from the experience I’ve gained from performing start-to-finish installations of enterprise-class SCM tools including IBM Rational ClearCase and CA Software Change Manager. What separates these tools from Git (and SVN) is that they address processes and workflows, security and roles. And the enterprise world is all about that.
A standard installation of Git, on the other hand, is a blank slate. You can do what you will with it. Which is great for a developer who dreams of having that flexibility but gives SCM admins nightmares because they usually have to clean up whatever goes horribly wrong.
What allows Git to have a chance of making serious inroads into the enterprise world is that it’s open, relies on standard mechanisms such as ssh and has a hook system that is triggered by actions on a repository. New functionality can be constructed around the version engine core.
So what exactly does Git need to have built around it?
My minimum set of requirements would include
1. Security and Access Control
Git punts on security and relies directly on the OS/filesystem and transport protocol (git:, http:, or ssh:) to control read and write access to repositories. And current add-ons such as gitosis only address access at the repository level, not the level of branches, tags, etc.
Implementation of a unified security and a fine-grain access/locking mechanism is an absolute necessity before Git can be even considered as a serious enterprise tool.
2. Integration with the “typical” Development Environment
My experience with Git is with Rails and Mac OS X and Linux. While this isn’t unusual in the startup world, it’s not the “typical” enterprise development environment. That instead would be Visual Studio or an Eclipse-based IDE on Windows.
We need to support projects such as
- msysgit - a native Windows implementation of Git
- JGit - a Java GIT library implementation
- EGit - an Eclipse plugin based on JGit
if Git is to gain traction in the enterprise.
3. Repository Visualization
If you have development of even the slightest complexity, having a visual tool to view the branch structure and where commits are located is a necessity. Some existing GUI interfaces include:
- git-gui (multi-platform tcl/tk)
- gitk (multi-platform tcl/tk)
- qgit (multi-platform Qt)
- GitX (Mac OS X)
- Git Extensions (Windows)
These tools, however, work on just local repositories. Remote repository branching is only seen if you’ve fetched the information.
An enterprise tool will need to start from any “canonical” shared repository and then add branching information from local developer repositories in order to show the extended branch network. This would provide a visualization of the development taking place across the organization.
4. Example Workflows
Git doesn’t mandate any particular development workflow. Even the de-facto standard pull-request method of sharing updates is really a suggestion rather than an enforceable process (unless you’re working under a benevolent dictatorship).
Unfortunately you’re going to find that given n developers, you’ll likely see a minimum of n+1 ways of using a tool.
Example enforceable workflows for common practices including agile development, lifecycle management and deployment need to be created via the hook mechanism and made widely available. An enterprise SCM team can then use these workflows as a starting point for customizing their Git installation.
5. Simplified Administration
Installing and using Git for a local repository is reasonably straightforward. Configuring a repository for remote access is a bit more complicated:
- How do I create a bare repository from an existing one?
- Which protocol should I use? git, http, or ssh?
- How do I restrict access?
- How do I add and identify repository users?
- What happens if I need to add a new repository?
And if you have to host any appreciable number or sizeable sets of repositories, you need to start worrying about storage, load, and backups.
So is this at all possible? Can an enterprise-ready tool be built around a Git core?
Absolutely yes.
If you have any doubts, you just need to look at what GitHub has done with simplifying repository creation/forking, security and collaboration setup, and tools for visualizing the development network. Or how Heroku has made Git a part of the application deployment process.
It’s just really a question of when someone’s going to put it all together for the enterprise.
March 18th, 2009 at 2:20 pm
Thanks for providing this perspective. It’s nice to see Git in a more general SCM context.
March 24th, 2009 at 3:49 am
Really really interesting article. I share any of the ideas.
I cited GitHub as an example of simplified but powerfull collaboration tool. But it is a closed app. What about gitorious? It seems to share many of the goals of GitHub, but it is free software. So, it can be “easily” deployed inside an enterprise.
http://gitorious.org/
March 24th, 2009 at 1:48 pm
Seems you forgot qgit (or qgit4), a nice and usable Qt-based GUI
http://git.kernel.org/?p=qgit/qgit4.git;a=summary
March 24th, 2009 at 8:32 pm
@Guyou-
Gitorious provides a good start for anyone who wants to put together a simple to use site for hosting Git repositories. And as open-source software, it can be extended to address security requirements and automatically add hooks to control workflows.
However, enterprises are likely to wait until someone else implements those features rather than developing it themselves. And the GNU AGPL license may also present a roadblock in adoption. It shouldn’t, but my experience with Insoshi, which also uses that license, has been that companies are concerned about the conditions under which they may be required to release source code. (This would only apply to modifications to the gitorious code, not any code stored in a hosted Git repository.) And one thing to keep in mind: enterprises are willing to pay for a closed application because support is included.
@Stefan-
I probably missed it since I don’t have Qt installed on my MBP. I’ve added it to the list. Thanks.
March 24th, 2009 at 11:27 pm
We’ve had good success developing *and* deploying without the use of addons.
A setuid update hook and git-shell solve the access problems over ssh, and a cobbled collection of shell scripts that tag and deploy tags run our deployment process.
Being able to work with the repository on production servers (in the worst case), and generate a patch has actually been a complete boon in our environment…. at least, I like to think so.
BTW, we’re a mod_perl shop, so we’re a little different than the normal git crowd.
March 25th, 2009 at 2:59 am
I work on a small team that develops shrink-wrapped Windows software. At first, we used a single, centralized git repository for the entire team. And you’re right-in that mode, git provides no security or access controls.
But after a few months of using git, we realized that there was a better way (at least for us): Every developer should get their own repository. In this configuration, only the team lead has write access to the main repository, and all patches are reviewed by the team lead. (Alternatively, you can give write access to a pair of senior developers, and have them each review the other’s patches.) This works surprisingly well, because git makes code review very easy.
The main repository has receive.denyNonFastForwards set to true, so no data can actually be lost (except by branch deletions). And we make sure that we have both reflogs and a robust offsite backup system.
Under this model, only your team leads have write access, and even they have extremely limited ability to destroy data. But team members can still collaborate and work independently of the team lead when necessary, and then submit the resulting code for review.
When you think about it, the Linux kernel is an order of magnitude larger than most enterprise projects, with a fairly draconian review process (or so it looks from reading lkml). And git was designed to operate well in that environment. So there’s a good change that some technologically-aggressive enterprises could use git today, provided they get the workflow right.
April 14th, 2009 at 10:30 am
Thanks for the interesting article.
You forgot about http://code.google.com/p/tortoisegit/
June 7th, 2009 at 7:01 pm
> Git punts on security and relies directly on the OS/filesystem and transport protocol
No, git doesn’t punt (“To retreat from one’s objective.”) on security. It’s agnostic, allowing you to implement your own. Git has support for “hooks”. For example, the update script can reject an update on the server based on anything (the contents of the file, the user pushing, etc. In fact, git has support for signing commits, so you could have an ops guy who only has authority to push updates signed by QA.)
> Integration with the “typical” Development Environment
> Example Workflows
> Simplified Administration
I only half agree with the sentiment that “git should be simplified for the masses”. There are some rough edges in git for sure. But at least it’s pretty hard to loose data without a stern warning first. Forcing one workflow on git is wanting to kill the goose that lays the golden egg.
But the “typical enterprise” could learn a lot from open source. It’s their loss if they don’t use git, we don’t care either way.
> How do I create a bare repository from an existing one?
cp -r repo/.git ~/bare_repo
> Which protocol should I use? git, http, or ssh?
Http is just a back-compatibly thing, don’t use it. Use SSH if you like encryption and don’t want to run another server.
> How do I restrict access?
To what? SSH and git hooks plug right into the infrastructure you already have, if you have a Linux server.
> How do I add and identify repository users?
Isn’t that what gitosis is for?
> What happens if I need to add a new repository?
You can create as many as you need, it doesn’t cost extra.
January 16th, 2010 at 3:32 pm
Quoted your statement of git needing fine-grain access control on http://www.meetup.com/ocdrupal/messages/boards/thread/8087494/#33174391 which asks how to do fine-grained access control in git.
August 25th, 2010 at 9:36 pm
fine-grained access control for writes: try gitolite, it’s pretty damn good
PS: Im the author so I’m biased
November 14th, 2010 at 4:54 pm
I think that some people are missing the point here. Leveraging the current callbacks framework exposed by git is anything but granular and access control ultimately comes down to a “gentlemen’s agreement” of sorts between the developers (anyone who has any push access) and the repository maintainers. The original poster above here was quite correct, git access control is nothing more than a shell game, it is offloaded to the OS/filesystem or obfuscated with a callback hook. The ability to push into a git repository requires that the pusher have write access (or magic spells), and with that write access (or the aforementioned spell-craft) they can ultimately do as they wish.
Don’t get me wrong, I love git and I use it for all of my personal development and a good deal of my work development as well, but until git has a real, inherent access control mechanism it will never be taken serious in the enterprise environment.
Anonymouse comments:
June 7th, 2009 at 7:01 pm
> But the “typical enterprise” could learn a lot from open source.
and the typical script kiddy could learn a lot from the enterprise.
February 19th, 2011 at 7:13 am
We are a group of developers working in a large enterprise (one of the biggest Telco in the world) and since we adopted Git we recognized almost all the issues mentioned by the op. Because of that, we have been working, since last year, on a solution for those problems. We have developed a host based service (that can be also installed on site) that delivers a nice web interface to manage your repositories, your users and groups, and security at very fine grained level
1. Security and Access Control
We provide read/write access control over repositories and, at branch level, control over READ / CREATE / PUSH / PUSH-FORCE / DELETE right out of the box trough a pleasant web interface.
Every access to Git repository is secured via SSL/TLS with FIPS 140-2 certification and SSH Protocol, required for Enterprise-wide source code repositories. GitEnterprise does not rely on the system SSH Server and then does not expose any security risk on the underlying OS.
All the external access is centrally audited with ability to extract the information needed for SOX Compliance Report
2. Integration with the “typical” Development Environment
We are currently evaluating the feasibility to drop some work on the Git plugin for Eclipse, but this is not part of our core scope
3. Repository Visualization
A web interface is available for repository visualization, and it includes a full repository navigation system based on the popular CGit (http://hjemli.net/git/cgit/ ).
4. Example Workflows
We think this must be agreed within the enterprise / project scope. What we have in our enteprise is a de-facto central repository that produces the official builds then are taken trough the delivery process (which, in our case, is composed of three level of testing and two deployments)
5. Simplified Administration
(but we’re happy to improve!)
The administration is really simple. Everything is done trough a simple web interface. You can import, connect or define your SCM users of your organization, setup security domains and groups, list you repositories, identify users, groups and permissions, create and destroy repositories. Almost everything you can think of is in place, well, at least all the things that were requested to us by our customers until now
GitEnterprise (that’s the name of the thing) is also available on a freemium base: you can get a 10 users / 1GB account for free. We encourage everyone to give it a try and provide us some feedback!
March 1st, 2011 at 5:57 am
It should also be noted that using native git you can currently commit in behalf of someone else, so “stealing” his identity. With GitEnterprise this is currently (of course) not possible, as it validates the committer email/name with the profile corresponding to the credential used to access the repository. This is a huge advantage for an enterprise environment, believe me
April 1st, 2011 at 2:50 am
GitEnterprise sounds excellent. i have passed the info along with the gitolite reference to our IT team in Stockholm
April 8th, 2011 at 9:58 am
Ok our IT team in Stockholm say the gitolite is extremely interesting and will be in touch for more specifications. thanks again for this info
DM
April 14th, 2011 at 2:38 am
Are you a solo web developer or maybe you work as a team? Well, if that’s the case, you would want to use Git. So what difference does it have from all the other installers out there? Well, for one, once you install Git. It’s standard installation is a blank slate. You are very much free to do whatever you please with it. what does every developer dream of? It could be the liberty and the flexibility that can be offered to them while using the said program.
May 3rd, 2011 at 6:24 pm
I got some points of you. I know this distributed revision control system really helpful but for me it’s a little difficult to use this software. Let alone I am only an individual developer so I won’t use Git.
Anyway, thanks for sharing it although I don’t use Git, I got some points of there.
Regards,
Stewart
May 5th, 2011 at 8:48 am
Hi !
May 26th, 2011 at 5:15 am
Installation of Git is an advantage though it is a blank state. You can do whatever you want with it. It is a great idea for those dreamers to have a flexibility but still having problems and needs to clean up what have done wrong. Another thing about Git is that you can import and connect your users organization, Whatever you think is in properly place.
June 7th, 2011 at 8:17 am
Пишите больше!
June 9th, 2011 at 8:14 am
1. Security and Access Control
Using a distributed version control system like git, you need write access to your own remotes (ssh) and others need read access (git protocol or possibly http). It is as simple as that.
All other wishes are just based on a misunderstanding of the distributed concept and that is very common. Eclipse project and their hooks for validating committers is an extreme example… sad…
In a corporate environment you need to protect all data that you don’t want to share with the world. The protection of secret data in most places is usually a joke and there is no real point in asking for more in the DVCS so putting the git: and http: servers behind the corp firewall would keep the data in the DVCS repos as (un)protected as the rest of the secret data. Local repos should be on encrypted drives if you care.
2. Integration with the “typical” Development Environment
Plugins are typically something that you should avoid. It creates extra work because most people are using DVCS for many different kinds of projects. That means, either you learn you DVCS once an for all or you learn how to use it in a variety of different ways depending on what IDE or other environment you are using or what plugins you currently like.
3. Repository Visualization
Use gitk and git-gui or install a git server somewhere. Gitorious works well and is reasonably easy to install on your own servers if you follow the instructions.
4. Example Workflows
Use the same as Linus… Why would you mess up things by using a non distributed workflow just because you are in a corporate environment… Except from start using Git, projects leaders must make is clear to the subordinates that the work is not done until they have pushed it to their public remote so that the project leaders can pull. And this is the most difficult thing in the whole chain… to make project leaders understand why they need to use a DVCS at all…
5. Simplified Administration
I have installed a gitorious server… It works wonderfully well but it contain lots of features that you really don’t need, like multiple committers for one repo and teams etc… Administrative effort is basically zero… Users are registering themselves and they create repos or clone existing repos by themselves.
July 26th, 2011 at 10:40 pm
Good feed No wonder why Christian Dillstrom had a book mark to this blog post, so you are doing a great job as mobile and social media marketing whiz provides a hyperlink to you.
September 21st, 2011 at 9:38 am
I am putting together a Git solution for the Windows Enterprise at: https://github.com/otac0n/WebGitNet
We are adding access control in the coming releases, and workflow in the next. It would be great if your could take a look and tell us what you think!
September 24th, 2011 at 4:39 pm
Nice post about gitguru » Git Enterprise Requirements. I am very impressed with the time and effort you have put into writing this story. I will give you a link on my social media blog. All the best!