Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Enterprise 2.0

enterprise.github.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: GitHub Enterprise 2.0

#61

Post by teacup50 »

buckie wrote: post #50

Over a year I started the process of convincing the people I needed to at my job (Federal, Non Defense/Law Enforcement) to get an instance of Github Enterprise installed. Though it took a lot of time and effort, I managed to get both the approval and funds needed for a small scale - 10 user - install (on my 3rd try, gov't is really against change). Our current "enterprise" VCS is PVCS (so old I had to look it up). Th…

Consider Atlassian's Stash: https://www.atlassian.com/software/stash

Similar feature set, but otherwise better in almost every way (and I don't work for Atlassian, just for the record). Some examples:

- Source code is provided when you purchase a license, and you have the right to modify it (just not distribute it). Whether or not Atlassian is still around in 10 years (they probably will be), you'll never be left in the cold with something you can't maintain, or bugs that can't be fixed.

- Pricing is up-front and non-discriminatory. The prices are listed publicly, and you can buy it on your Amex, right now, without ever speaking to a sales team (unless you want to).

- Distributed as an installable application, not an opaque VM like GitHub Enterprise, so you can provision it in any environment, not worry about out-of-date OS components, dealing with an opaque black box you can't administer directly, or any other similar issues.

- Extension API. You (very easily) can write extensions that hook into just about any aspect of Stash, without having to work with an external REST API (unless you want to — it has a REST API, too). Atlassian provides a built-in extension "app store" for both free and commercial extensions, and there are a lot of great free (and open source) extensions out there.

Re: GitHub Enterprise 2.0

#62

Post by incision »

buckie wrote: post #50

Over a year I started the process of convincing the people I needed to at my job (Federal, Non Defense/Law Enforcement) to get an instance of Github Enterprise installed. Though it took a lot of time and effort, I managed to get both the approval and funds needed for a small scale - 10 user - install (on my 3rd try, gov't is really against change). Our current "enterprise" VCS is PVCS (so old I had to look it up). Th…

>"Apparently, the $5k minimum order was too small for them to care (at least that's what my side says)."

I find this to be pretty typical behavior when representing Government to vendors.

It doesn't impress me as being dismissive so much as indirect sales pressure.

A vendor knows that the typical Government agency can and does regularly piss away 10-100x that amount on systems that never see the light of day.

They're betting that if the initiative has any real support someone will find the funding to make it happen.

Problem is, this is probably worst possible tactic to take with someone in your position who is trying to enact change without substantial/any budget to command.

The people on your end are happy to walk away, they've already done it twice and they were surely just looking for a reason to do it a third time.

Word to salespeople working with Government:

When you're dealing with a lone "champion" inside some organization you should be thinking in terms of cheaply seeding for the future and having friendly eyes and ears inside - not booking a sale this quarter.

Also, as the OP points out, you're going to be dealing with entirely segregated procurement departments who are likely out of their comfort zone to be handling the task at all - not the sort you should be at all impatient, demanding or upselling with.

Now, to be fair I should point out that I think there are some valid reasons for vendors to avoid small deals.

The main thing is perception. The naysayers are going to attack any new installation the moment it hits the floor. If a minimal install isn't defensible against a hostile environment like that seeing it fail will kill any potential future business for the vendor.

A simple way to mitigate this is sign an agency up and leave them fully-featured and uncapped - no friction to grow the product internally. Then, this is important, resist the urge to demand a huge true-up once things have taken root, just ramp up gradually and understand that the social proof of your having your product fully-established in one such agency will open the door to sales elsewhere.

Re: GitHub Enterprise 2.0

#63

Post by iancarroll »

fsiefken wrote: post #35
iancarroll wrote: post #31

Earlier quoted context omitted.

GHE requires a lot more resources then GitLab (8GB/4cores min) and anything lower slows it to a crawl, which is a shame. Luckily there's now an AWS image which makes it significantly easier (deploying it now). GHE is very social, GitLab never had that feel for me. Same feature set, really.

In my experience GitLab runs well on 1 core and 1 GB. Are you also deploying it on a 8GB amazon instance? How important are GHE's social features within an enterprise environment?

It is actually locked to instances above m3.large, so I have to redeploy to xlarge or the like.

Can't say much about an enterprise environment. The UI is superior IMO.

Re: GitHub Enterprise 2.0

#64

Post by arturnt »

GitHub's tools always fell short for me. Phabricator is a much better code review tool (with a commandline workflows). Trello / JIRA are a lot faster and more flexible for issue management or sprint workflows.

Re: GitHub Enterprise 2.0

#65

Post by imbriaco »

korzun wrote: post #44
microtonal wrote: post #36

Earlier quoted context omitted.

Just wondering, not an attack: did you talk to the Debian project to see what resources (money or person-time) are needed to support a Debian release for a longer time? I am asking, because Debian is a community project and in the end it gives what its community members are putting in. I am wondering about the amount of effort necessary. It seems that they estimate it at one person, full time [1]. Which does not seem…

Why would they talk to anybody? Support decisions were already made (for a reason) for both releases. Trying to revise them and committing on '?' for an array of production servers is a horrible idea.

Exactly this. It would have seemed pretty presumptuous to ask the Debian project to change the support model that they decided worked for them to support us.

We were also faced with a very large new infrastructure build and we knew we were at the end of the line with Squeeze but Wheezy had't quite yet shipped, which put us in an awkward position.

Debian is a great distribution, but at the time we felt like Ubuntu was the right way to go given the existing support policies.

Re: GitHub Enterprise 2.0

#66

Post by dkuntz2 »

atbell wrote: post #59
killnine wrote: post #29

Can someone who has used both this and Gitlab provide an insight on how the experiences differ?

As someone who's used both Gitlab, Github Enterprise, and Stash in a corporate environment, I have to admit I prefer GHE, for the features it shares with core Github, if nothing else. My only gripe w/ GHE is the lack of branch-based ACLs. If we want to implement a Github Flow ( https://guides.github.com/introduction/flow/index.html ) methodology, but also have automatic branch detection and testing in our CI (Jenkins…

I'm pretty sure GHE has the ability to disable pushing to the default branch (which is set on a per-project basis, but by default it's master). But I think this is a per-instance setting (unless that's been changed recently).

So while everyone would have the ability to push to other branches, they wouldn't be able to touch master outside of pull requests, which I think is what you want anyways.

Re: GitHub Enterprise 2.0

#67

Post by teddyh »

Thaxll wrote: post #55
teddyh wrote: post #51

Earlier quoted context omitted.

> Debian didn't give us any certainty beyond a few months out. Actually, now they do: https://wiki.debian.org/LTS

Not even close: "Debian-LTS will not be handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success (with some overlap in people involved)."

How is this different? Unless you know the security team personally, how does it matter which people does the job? It is still officially a Debian project, backed by those volunteers who does the job.

Re: GitHub Enterprise 2.0

#68

Post by buckie »

benbalter wrote: post #57
buckie wrote: post #50

Over a year I started the process of convincing the people I needed to at my job (Federal, Non Defense/Law Enforcement) to get an instance of Github Enterprise installed. Though it took a lot of time and effort, I managed to get both the approval and funds needed for a small scale - 10 user - install (on my 3rd try, gov't is really against change). Our current "enterprise" VCS is PVCS (so old I had to look it up). Th…

> A couple months ago, the entire thing collapsed on my face and we went with gitlab instead. Why? Because github's sales team f*ed it up. Apparently, the $5k minimum order was too small for them to care (at least that's what my side says). Too bad, I really wanted to get them in the door. Ben Balter from GitHub's government team here. I'm sorry to hear we let you down. Please let us make it up to you. You (or anyone…

This is all really great to hear, I've already begun the process of restarting the engine. It will likely take me 3-6 months just to get the momentum needed to reach out again officially. Oh the gov't...

> I'd love your input on how we can do better.

As I'm not in procurement and don't want to make assumptions about how your shop is run I don't have any comments of merit/meaning beyond my previous ones & saying an honest thanks for your reply and I hope that I can get my guys to reach out to you sometime next year.

Post reply on HN