
GitHub Enterprise 2.0 - jglovier
https://enterprise.github.com/releases/2.0.0
======
buckie
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). The idea
was to get github installed on a small scale, gain support and extend it to
the entire agency over the course of a couple years. Everyone who deals with
PVCS wants git, but the management don't care to put in the effort to get it
initially, so gaining the support would be easy.

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.

I'm sure it's just a bad egg in the sales, but seriously there are some people
trying to fix/modernize gov't tech from the inside and thing's like this don't
help. I guess my only recommendation is that if your company usually sells to
private and the gov't asks for a small-sized purchase please be flexible. The
guy who caused this request to happen has likely been putting in a huge amount
of effort and has larger plans for integrating your service over time. The
person who is contacting you is not that guy, has no idea what your product
(or any tech) is/why it matters and is usually doing the originator a favor.

~~~
benbalter
> 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 else) should feel free
to reach out to me any time at government@github.com, and I'll personally help
navigate the process.

For what it's worth, we care a lot about the experiences of all our users,
whether you're a developer using the GitHub.com front end, a system
administrator spinning up GitHub Enterprise, or a COTR procuring a license for
your agency. I'm not part of the Sales team. In fact, my full-time job is to
help empower those working to "fix/modernize gov't tech from the inside", and
a big part of that over the past year or so has been seriously leveling up the
user experience for government and other large enterprises.

To help here, we now have a dedicated government team
([https://government.github.com](https://government.github.com)) that makes
sure our front-line sales reps and supportocats are conversant in "govspeak",
a semi-private government peer group
([https://github.com/government/welcome](https://github.com/government/welcome))
to collaborate on best practices, and are streamlining the procurement process
for government with invoicing and standardized contract vehicles (and now
FedRAMP support as part of AWS). I'd love your input on how we can do better.

~~~
buckie
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.

------
akerl_
Related blog posts:

[https://github.com/blog/1918-a-faster-more-flexible-
github-e...](https://github.com/blog/1918-a-faster-more-flexible-github-
enterprise)

[https://github.com/blog/1919-the-story-behind-the-new-
github...](https://github.com/blog/1919-the-story-behind-the-new-github-
enterprise)

------
bsimpson
> Current Version: 2.0.0

> Previous Version: 11.10.348

I see GitHub is utilizing lexicographic semver.

------
npongratz
> GitHub Enterprise now utilizes Ubuntu 12.04 LTS...

I'm curious, why is this new release based on Ubuntu 12.04 LTS rather than
14.04 LTS?

I'm mainly interested in the thought process behind this choice, I don't have
an opinion about it.

~~~
skywhopper
14.04 is too new. They probably started working on this long before 14.04 was
finalized, and retooling would be expensive and slow them down. And even then,
14.04 is still rough around the edges--not all of the kinks have been
discovered or fixed yet. 12.04 still has over three years of life left in it,
which is much longer than the probable lifetime of GHE 2.0, and a future
release of GHE can upgrade to 14.04 if and when that's necessary/beneficial.

~~~
nilsimsa
So a stable release is too unstable for them? And now the first thing users
will have to do is after install, apply all the bug fix packages to bring it
to 14.04. But that will bring no unstability concerns? Or will they just not
patch it and expose themselves to the bugs in the name of stability?

~~~
imbriaco
That's incorrect. The way you apply bug fixes to 12.04 LTS is by installing
the bug fixes, not by moving to 14.04. The whole point is that 12.04 LTS
continues to get updates for 5 years.

------
creade
This isn't the thing they've been teasing though, right?

[https://twitter.com/github/status/531914601248882689](https://twitter.com/github/status/531914601248882689)

~~~
gjtorikian
This is the thing, yes.

------
guiomie
How can I see the pricing ?

~~~
iends
I spent a huge amount of time trying to find pricing. Bad UI/UX.

~~~
claudiug
intentional ui

~~~
atonse
It's very likely buried at the bottom of features since it's the thing that's
likely to make some shy away even before they see all the good features.

Edit: In all honesty though, even though it does seem expensive, if you have
20 seats (20 developers), your payroll is already on the order of $1MM+, so
$5k a year is almost a margin of error at that point, considering those devs
use it all day every day.

~~~
techdebt5112
it's more than 5x what Atlassian charges for the same product

------
Igglyboo
Does anyone know how this compares to Stash? Been using bitbucket for a while
but wanted to switch to a self hosted version soon.

~~~
modoc
It is significantly more expensive, especially for teams in the ~100+ range.

We've been using Stash (and Jira, Confluence, etc..) pretty happily. GitHub is
great, but the $$$ is just too much, and the Atlasssian ecosystem integrates
nicely.

~~~
dan_blanchard
Yeah, and the worst part is that GitHub doesn't even offer the same suite of
services you get with the Atlassian ecosystem. It'd be one thing if it were a
bit more expensive, but also included CI and a more full-fledged CMS like
Confluence.

That said, ff they dropped the price, my team would switch in a heartbeat,
because we use GitHub and Travis-CI for all our open source stuff.

------
kordless
Somewhat related, I just finished up the Splunk demo instance launcher on
StackMonkey:
[https://www.stackmonkey.com/demo/splunk/](https://www.stackmonkey.com/demo/splunk/).
It would be interesting to be able to deploy GitHub Enterprise as a demo as
well.

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

~~~
atbell
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](https://guides.github.com/introduction/flow/index.html))
methodology, but also have automatic branch detection and testing in our CI
(Jenkins/Bamboo/whatever), we end up having to assign all users the ability to
create branches in the given repository (which, in turn, gives them the perms
to push to master). I'm actually quite surprised that this hasn't been
implemented yet in GHE; I can understand why GH wouldn't have it, but GHE
(because of the nature of its user base) really should.

That issue aside, the UI in GHE is simply superior to GL and Stash.

~~~
dkuntz2
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.

------
thebruce
"Configuration runs no longer use Chef and are much faster and more reliable."

What replaced Chef?

~~~
mikemcquaid
We're using Puppet on github.com but GitHub Enterprise didn't warrant the use
of either so: nothing.

~~~
mtodd
s/nothing/bash/ ^_^

------
AhtiK
"GitHub Enterprise /.../ support for rendering PSD files will have your design
teams jumping for joy."

I keep wondering how they do the PSD file rendering, sounds very intruiging.
Is there a separate "thumbnail" automatically included in every PSD file or is
GitHub doing a real PSD file rendering? In that case I wonder about font
availability etc..

~~~
Matumio
PSD files may contain a full resolution rendered (flat) bitmap for
interoperability. It's probably enabled by default when saving. Other file
formats like ODT and ORA contain a rendered thumbnail (e.g. 256x256) just for
fast preview in file browsers. Scaling down a couple of 20000x20000 images in
a folder is no joke, and that's not an unusual size for digital artists.

------
reledi
Congratulations on the launch, GitHubbers!

------
tsax
Kinda off-topic but I instantly pattern matched the site UI to Heroku. Anyone
else feel the same?

------
kbar13
changelog looks pretty awesome and I'm pretty excited.

Upgrade process doesn't look too fun though... Gonna have to do a side-by-side
migration; no upgrade package provided.

------
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.

------
warcode
"Introducing a faster, more flexible GitHub Enterprise... unless you wanted
more flexible pricing"

