Live data from Hacker News

GitHub Enterprise 2.0

enterprise.github.com

41–50 of 68 posts

Re: GitHub Enterprise 2.0

#42

"Configuration runs no longer use Chef and are much faster and more reliable." What replaced Chef?

Expanding on what mikemcquaid and mtodd said, essentially it's been replaced with bash and a sprinkling of ruby (Mostly for templating, IIRC).

Me saying "replaced" is a bit of a misnomer though because the way we create, maintain, and configure Enterprise is totally different now making Chef and Puppet overkill for our uses. We no longer try to maintain the state of the entire system throughout upgrades instead favoring placing a complete system (built using mostly bash and again a bit of ruby).

Since we only now need to change a few configs we can do that using bash and ruby. This resulted in huge speed ups when reconfiguring Enterprise.

It's hard to over emphasize how much of the underlying way that Enterprise was put together changed and was improved with this release. Everything from developing on it, to releasing it, to deploying it, to upgrading it has all been shifted.

Huge respect to the infrastructure folks that made this happen (certainly made my life easier as a dev!).

Re: GitHub Enterprise 2.0

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

Re: GitHub Enterprise 2.0

#44

Earlier quoted context omitted.

I was part of the Ubuntu decision at GitHub, and it was based on the fact that Ubuntu gave you much longer support after the next release. Debian (at the time) only guaranteed even security updates on previous releases for one year after a new release.

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.

Re: GitHub Enterprise 2.0

#45

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

I've never used GitHub Enterprise, but my experience with GitLab is not so great. If GHE is a beefed-up GitHub, it's probably much cleaner. My major gripe with GitLab is that it's really hard to navigate around. There are lots of links that take you somewhere other than what you'd expect. The landing page for projects is the log, you have to click a tab to see README and file structure, which I've always found clunky…

Our experiences with GitLab have been really positive. GL may not be on par with GHE UX wise, but I don't really feel that this has been an issue for us. Coming from GH or GHE, GL is a little more difficult to navigate, but it's getting better with each release. The thing that probably bugs me the most is the home page for a repository being the activity stream. However, considering that we're saving $25k per year by using GL over GHE, I can happily put up with it.

I've never encountered the search issue you describe. We're using the latest GL, perhaps it was a problem with an older version?

Re: GitHub Enterprise 2.0

#46

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

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…

Right on, but tiny correction - 12.04 has over two years of life left, not three.

Re: GitHub Enterprise 2.0

#48

Earlier quoted context omitted.

We're running 12.04 on github.com so made sense to sync them up.

Why Ubuntu over Debian, out of curiosity? I've seen Spotify switch from Debian to Ubuntu and regretting it already.

When I made the decision for my shop, we chose Ubuntu because of the guaranteed support cycle. Debian's support windows were too short, and we need to be able to plan years ahead of time for when we must spend the time to upgrade the OS. It takes a lot of testing and tweaking, and Debian didn't give us any certainty beyond a few months out. Ubuntu gives us a five year guarantee (and they've been sticking to that for six years now). That allows us to be a lot more confident about making plans for the next year or two.

Re: GitHub Enterprise 2.0

#49

Earlier quoted context omitted.

I've never used GitHub Enterprise, but my experience with GitLab is not so great. If GHE is a beefed-up GitHub, it's probably much cleaner. My major gripe with GitLab is that it's really hard to navigate around. There are lots of links that take you somewhere other than what you'd expect. The landing page for projects is the log, you have to click a tab to see README and file structure, which I've always found clunky…

Our experiences with GitLab have been really positive. GL may not be on par with GHE UX wise, but I don't really feel that this has been an issue for us. Coming from GH or GHE, GL is a little more difficult to navigate, but it's getting better with each release. The thing that probably bugs me the most is the home page for a repository being the activity stream. However, considering that we're saving $25k per year by…

Looks like we're still on 7.3.1. I don't see anything in the release notes for more recent versions about syntax highlighting, but they might have snuck something in, or it could be a dependent package change.

25k sure is a lot of money. Then again, can you put a price on the frustration of developers used to working with something better? Maybe.

Re: GitHub Enterprise 2.0

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

Post reply on HN