
GitLab Master Plan - dwaxe
https://about.gitlab.com/2016/09/13/gitlab-master-plan/
======
PaulRobinson
It's interesting to me how much effort is being spent on adding tools like
issue tracking, build pipelines, deploy management, etc. vs just providing
good hooks for standalone tools that do all those things.

We have discussions about Jenkins vs Concourse, where to keep ansible vault
passwords, should documentation live in Github wiki or in Confluence
(apparently "tech" documentation in the form, "business" documentation in the
latter - what if it's both? Who decides?), and so on.

There is something nice about being able to go to a single place and saying
"OK, it's all here in this box". Github has made inroads with some of this
stuff, but not quite enough. Gitlab could try and do all this, but then people
will moan ("I prefer JIRA/Trello/whatever").

Most of the pain around developer/business workflow around us at the moment
actually comes down to the fact that nobody has _really_ thought about
providing a great unified UX for all of this.

Part of the concern is people want to be "flexible". No, dictate, just make
sure what you dictate is a better solution to what people have.

If GitLab get it right, github could be a minor player (unless they keep up)
in a few years time.

~~~
bobbyi_settv
> nobody has _really_ thought about providing a great unified UX for all of
> this.

Isn't the Stash-Jira-Bamboo-Confluence stack a unified UX for doing all of
this (source control, pull requests, deployment, docs, issue tracker, build
pipeline, etc)?

It may not be a _great_ UX, but can we at least give Atlassian credit from
probably having _thought about_ it having a great UX?

~~~
nathan_f77
That's funny, because you're right, and Atlassian has an enormous head start.
And it's hard to explain why I like GitLab so much more.

I used the entire Atlassian suite for 3 years at my first web development gig,
when I started over 7 years ago. I just have all these memories of things
being ugly, slow, and hard to customize. Although I had a mostly positive
experience with Confluence. Bamboo was just not nice to use. BitBucket does
most of the same things, but it just didn't feel nice to use. Maybe it's the
UI, or the dark blue theme. Maybe it's purely psychological, like GitHub was
the place where all the cool developers hang out, and BitBucket is the
corporate nerd who just wants to fit in so they give away all their private
repos for free. So I dumped my private, personal stuff on BitBucket, until
GitLab came along.

And honestly, up until the last few months, I actually really disliked GitLab.
I kind of saw them as just rip-offs who were blatantly copying GitHub, and
stealing their customers. But then I realized that GitHub hasn't really done
anything interesting for years and years, while GitLab is working on all these
awesome features and integrating things that GitHub should have been doing
years ago. So now my opinion is that GitHub had their chance, and they blew.
GitLab is the new cool place to host your code.

~~~
technomancy
> And it's hard to explain why I like GitLab so much more.

In my case having the Atlassian all tools look the same seems to have
backfired; every time I go to BitBucket it makes me think of Jira, which makes
me cringe and wish I were on a different web site.

------
HorizonXP
We are currently on Github and are using CoreOS' Quay.io private Docker
registry with Github hooks for automated build creation. Total cost: $50/month
for Github for private repos, and $100/month for CoreOS' managed service that
includes Quay.io.

Years ago, I did set up our own private Docker registry and build server, but
it was a lot of work to setup and maintain, so I killed it. Hopefully and
probably, that's become easier to do today.

However, last night, I decided that I had had enough with our current setup
(it's slow, expensive, and cumbersome), and moved to GitLab. Here were the
steps:

1\. Create an account.

2\. Create a repository, and select the option to import from Github.

3\. Connect my Github account, and import all of our private repositories.

4\. Ensure Container Registry was enabled for the repositories.

5\. Create a .gitlab-ci.yaml file in each repository to build our Docker
images.
([https://docs.gitlab.com/ce/ci/docker/using_docker_build.html](https://docs.gitlab.com/ce/ci/docker/using_docker_build.html))

6\. Decide that I didn't want to use the Shared Runners.

7\. Spin up an EC2 Ubuntu instance, install GitLab's multi-runner.
([https://gitlab.com/gitlab-org/gitlab-ci-multi-
runner/blob/ma...](https://gitlab.com/gitlab-org/gitlab-ci-multi-
runner/blob/master/docs/install/linux-repository.md))

8\. Add the new runner to each repo.

9\. Start a build to ensure Docker image gets built.

In less than 10 steps, I was able to migrate all of our code and CI to GitLab,
in less than 2 hours. With the repository mirroring, Github can remain synced
to GitLab, so that I have time to modify our deployment scripts to use the
GitLab URLs instead. I'll be cancelling our GitHub and CoreOS subscriptions
this week.

As our team grows, we will likely host GitLab on our own servers, and I expect
that will go smoothly. I'll be happy to pay them at that time. Right now, I'm
really happy with this migration.

~~~
hackerboos
I've pretty much done all the steps you've listed. My problem now is how to
get those build docker images onto servers somewhere.

What services are people using for that?

~~~
sytse
You can also deploy from GitLab, see [https://about.gitlab.com/2016/08/26/ci-
deployment-and-enviro...](https://about.gitlab.com/2016/08/26/ci-deployment-
and-environments/) for an introduction.

------
asb
Right now, Gerrit and Phabricator give an almost unrivalled code review
experience - the ability to queue multiple comments up and submit them at
once, mark previous things as fixed, keep track of a patch as it evolves along
with the comments that were made against it. However the Github/Gitlab PR flow
is easier for most occasional contributors.

My question to Gitlabbers following this thread: do you have anything in the
works for improving code review to better match some of the use cases which
are handled so well by the Gerrit/Phabricator approach?

~~~
lima
Phabricator is a really solid GitHub alternative. Some of the largest open
source projects are using it and lots of companies.

I believe that the GitHub pull request workflow and issue tracker does not
scale to large projects and very much prefer Gerrit/Phabricator. Phabricator
was created at Facebook for a large development team (mobile apps) and it
shows. They have solutions for issues which only appear at scale (code
ownership in monorepos, for example - the owners/herald mechanism). It's also
very performant, has almost no dependencies and is extremely easy to deploy.

GitLab is a great GitHub alternative, but it's also copying its flaws.

Great writeup here: (not mine)

[http://cramer.io/2014/05/03/on-pull-requests](http://cramer.io/2014/05/03/on-
pull-requests)

HN discussion:
[https://news.ycombinator.com/item?id=7697132](https://news.ycombinator.com/item?id=7697132)

Good quote from that discussion:

> As far as code reviews go, this is pretty spot on. I was part of a a startup
> that was using GitHub pull requests for code reviews. As the team grew, it
> became more and more intractable, although not simply because of
> notifications. Side-by-side diffs and checkpointed diffs (so that you can
> see what changed since the last round of review and whether/how your
> comments were addressed) are handled very poorly by GitHub. We ultimately
> switched to Phabricator, and while there was a little friction as folks got
> acquainted with the new tool, it made code reviews a much more pleasant
> process. Recently, I had to go through a full code review back on GH pull
> requests, and it felt like pulling teeth in comparison. They're fine for
> interacting with contributors to an open source project, but compared to
> working with a tool like Phabricator that's built for a code reviewer's
> workflow (and for teams of engineers working together on a project), they
> just don't hold a candle, in my opinion.

~~~
jobvandervoort
We have many requests to improve our code review and make it more like
Phabricator and Gerrit.

We want to strike a balance between light-weight and powerful, but fully
intend to give you all the power of a Phabricator or Gerrit in GitLab. We're
working on several [0] initiatives towards this goal.

If you are interested in seeing these improvements in GitLab, please let us
know what is important and what we're not seeing!

[0]: [https://gitlab.com/gitlab-org/gitlab-
ce/issues/19049](https://gitlab.com/gitlab-org/gitlab-ce/issues/19049)

~~~
lima
I'm not a GitHub user myself, only have experience with GitHub. The article I
linked outlined it very well.

Essentially, what I need is code ownership (like Phabricator's "Owner" feature
or Chromium's OWNER file: [https://www.chromium.org/developers/owners-
files](https://www.chromium.org/developers/owners-files)) and essentially
what's outlined in the article I linked (diffs instead of heavyweight merge
requests).

~~~
sytse
Interesting, I created [https://gitlab.com/gitlab-org/gitlab-
ce/issues/22141](https://gitlab.com/gitlab-org/gitlab-ce/issues/22141) to
discuss.

------
exxo_
We (NVIDIA) recently moved away from Quay/Github/Jenkins to Gitlab for our
deep learning automation and the experience so far has been truly amazing. We
were able to automate our most complex DL container pipeline in a matter of
days. We still have to workaround some Gitlab limitations (e.g. issues
[CE]17069, [CE]18994, [CE]18106, [EE]224) but overall it's great to see
everything working in harmony (i.e. Docker registry, CI pipelines, Git
repositories, Runners on-premises). On a personal note, I would like to see
more storage on Githost.io instances considering the fact that you can't
easily delete pipeline traces and that Docker images can quickly add up.

~~~
sytse
Thank you so much for commenting. It is great to hear that the deep learning
automation department of Nvidia is using GitLab and is happy with everything
working in harmony.

Regarding your suggestions:

I asked to prioritize [https://gitlab.com/gitlab-org/gitlab-
ce/issues/17069](https://gitlab.com/gitlab-org/gitlab-ce/issues/17069)

We're already actively discussing [https://gitlab.com/gitlab-org/gitlab-
ce/issues/18994](https://gitlab.com/gitlab-org/gitlab-ce/issues/18994)

Not sure about [https://gitlab.com/gitlab-org/gitlab-
ce/issues/18106](https://gitlab.com/gitlab-org/gitlab-ce/issues/18106)

[https://gitlab.com/gitlab-org/gitlab-
ee/issues/224](https://gitlab.com/gitlab-org/gitlab-ee/issues/224) looks
interesting

Please comment in the issues if you have additional details about the use case
or questions.

The costs of GitHost.io correlate with the storage since they are Digital
Ocean instances. Not sure how to solve. Maybe by allowing to use their
networked storage, but this seems complex. Consider emailing
support@gitlab.com if you have any questions or suggestions.

~~~
Snappy
You can also switch your container registry to use S3, which might be more
cost-effective. I'm not positive if GitHost.io supports that, but it likely
does.

------
jbk
We use heavily gitlab-CE for VideoLAN (VLC, x264) on our hosted infra, and so
far we're very happy about it.

The only part blocking us from moving completely to gitlab and deprecate
everything else is mostly the limited issues tracker (compared to trac, for
example).

~~~
theunquietone
Great to hear you're happy with GitLab CE. What features do you need in issue
tracker that we don't currently have? Would love to learn more.

~~~
jbk
Well, mostly, I believe we need support for custom fields, so we have for each
ticket, the Platform, Component, Branch, Type, etc. And those fields can be
queried or made mandatory.

You can get then queries like:
[https://trac.videolan.org/vlc/query?status=assigned&status=n...](https://trac.videolan.org/vlc/query?status=assigned&status=new&status=reopened&component=!Bindings%3A+LibVLC+%28native+API%29&component=!Web+plugin%3A+Mozilla&summary=~asf&summary=~wmv&summary=~wma&summary=~mms&group=component&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&report=32&order=component)

And no, tags are not enough.

~~~
jobvandervoort
We have a few requests for custom fields [0], but we're worried with the
complexity that it adds to the application.

We might start to look into this again after we've shipped better issue
filtering, so that custom fields can actually be used effectively. [1]

[0]: [https://gitlab.com/gitlab-org/gitlab-
ce/issues/8988](https://gitlab.com/gitlab-org/gitlab-ce/issues/8988)

[1]: [https://gitlab.com/gitlab-org/gitlab-
ce/issues/21993](https://gitlab.com/gitlab-org/gitlab-ce/issues/21993)

~~~
jbk
> We have a few requests for custom fields [0], but we're worried with the
> complexity that it adds to the application.

I'm not surprised, but for us, it's mandatory to replace trac (or bugzilla)

~~~
connorshea
If you could chime in on one of those threads with your use-case and a mention
of the VLC project it may help get the ball rolling a bit faster :)

Even better if you have examples of useful fields you've used!

------
slap_shot
Just a few years ago I was in love with Github and felt nothing could ever
displace it. But as time went on, they just fell asleep at the wheel. I've
been using Gitlab for the last six months and there is no chance I would ever
go back to being a paying customer of Github. I'm so glad to hear GitLab
raised more money to keep going!

~~~
lloeki
Using both, I notice GitHub _has_ moved, but GitLab has moved in _precisely_
the direction we need internally, especially the latest release.

~~~
jobvandervoort
Great to hear! What exactly did we do well? What can be better?

~~~
StavrosK
As a customer, I love the integrated CI and how easily I can now run tests for
each commit and show pass/fail and coverage information right on the commit.
We used to use Stash and Jenkins, but it was pretty hard to get the
integration to work reliably.

Another thing I love is the gitlab-runner, which lets me spin up a machine and
have another server to run tests on.

What I really don't love is how limited issues feel compared to JIRA. Namely,
the following workflow is so hard it might as well be impossible:

* Issue gets opened by a user/assigned to a developer. * Developer has a view that's only issues that they haven't worked on or that they're working on. * After the issue has been worked on, the developer can assign it back to QA. * QA retests and closes.

This was very well served with JIRA's open -> in progress -> resolved ->
closed pipeline, as well as with the views that could filter things like "show
me issues assigned to me or nobody, that are not resolved or closed, ordered
by priority".

We tried to do something similar with labels and the board, but it's really
inconvenient, because we can't filter for "show me issues that are NOT
<something>". We used a "new" label instead, but the board doesn't know that
"new" is the backlog and that that label should be removed when the issue
moves out of the former.

In general, we've been having problems with issues, although the milestone
view is pretty fantastic.

~~~
jobvandervoort
Thanks for the awesome comment and details.

> show me issues assigned to me or nobody, that are not resolved or closed,
> ordered by priority

Right now, GitLab orders by priority out of the box on the board. You can
filter for yourself or assigned to nobody. Not both, but we're working on
improving the filters (including the option to do "NOT X OR Y". [0]

> We used a "new" label instead, but the board doesn't know that "new" is the
> backlog and that that label should be removed when the issue moves out of
> the former.

Just create a list with the 'new' label and you should be good, right?

We're thinking about having different types of lists in Boards, such as
'Milestone boards' and 'Status boards'. Something like that could solve some
of your requests as well.

[0]: [https://gitlab.com/gitlab-org/gitlab-
ce/issues/21993](https://gitlab.com/gitlab-org/gitlab-ce/issues/21993)

~~~
StavrosK
> Just create a list with the 'new' label and you should be good, right?

Yes, but then you have a "backlog" and a "new" list, which are no different,
and yet distinct :/

> Not both, but we're working on improving the filters (including the option
> to do "NOT X OR Y". [0]

That's fantastic, logical operators would be a great feature.

> We're thinking about having different types of lists in Boards, such as
> 'Milestone boards' and 'Status boards'. Something like that could solve some
> of your requests as well.

I think that, if you have powerful filtering functionality, then everything
could just be a filter. E.g. a board would be a list of filters with two
actions or an associated label (i.e. "show me all issues that are X AND Y (OR
NOT Z)", and assign label B when an issue is added here and unassign it when
removed). Issue lists could similarly just be a filter view ("show me the
issues with assignee=me or assignee=none and status=new or not
status=closed"), etc.

------
cygned
Honestly, installing and maintaining GitLab is still not a pleasure. The
Omnibus package was too unsafe for us because we wanted greater control about
versions and stuff; and the bundled pre-configured applications in it (e.g.
nginx) cause a lot of problems with existing installations.

We were basically not able to create a stable deployment on a machine also
running other services. But none of use really likes Ruby and rvm, maybe
that's also one of the reasons why we struggled.

~~~
jobvandervoort
I'd love for you to explain your motives behind not using Omnibus further.

Nowadays we provide images / containers for most major platforms, so there
should definitely be a good solution for you there.

That said, we make the Omnibus packages as that's the easiest and best way to
maintain GitLab. It takes all the work away from you. The vast majority of our
customers use Omnibus, even secure instances with thousands of developers.

~~~
__david__
Not OP, but I dislike many things about your omnibus packages. I hate packages
that install into /opt (thanks for the extra tld). I hate that it's 900+MB of
completely redundant junk—nginx? check, postgres, check, and entire ruby? git?
curl? _All_ of those are on my system already.

That said, I switched to it after maintaining a hand installed version and I
love how I don't have to run rails schema upgrades by hand any more. I used to
put off upgrading gitlab for months because it was such a pain and now I don't
have to think about it at all. Rails devs could learn a lot from php devs in
that regard (upgrading wordpress is absolutely trivial to upgrading gitlab).

So yeah, I love the omnibus package since it means I don't have to think about
it any more; I hate the omnibus package because it's a huge redundant monolith
and pure crap from the point of view of a Debian package purist.

~~~
Rondom
Debian stretch will have a native GitLab package.
[https://packages.debian.org/stretch/gitlab](https://packages.debian.org/stretch/gitlab)

Whether there are enough volunteers to keep it and its dependencies up to date
using backports remains to be seen, though.

------
user5994461
Conclusion from reading: Gitlab is just another open-source company that
raised money and is now desperate to monetize it's products.

Unfortunately for them. The market is already saturated with CI tools,
including good ones.

\- If you want good self-hosted CI, you use teamcity (jetbrains) or bamboo
(atlassian). Side note: They cost money, you get what you pay for.

\- If you want good SaaS CI, you use travis-ci (linux), circle-ci (linux) or
appveyor (windows).

\- If you want to suffer endlessly, you use Jenkins (previously hudson). It's
shit, it has a Bad UI, it's an aggregation of poorly maintained plugins, it
lack even the most simple features, the list goes on...

\- If you want to go exotic, you can find dozens of other [partial] CI tools.

There is no room for gitlab. Teamcity already has a free edition offering 20
projects and 3 slaves. All the aforementioned tools are free for open-source
projects.

Disclaimer: I have used all the tools mentioned above.

\-----

The reason the good tools are not popular is:

1) they cost money and people are bitches when it comes to spending even $10

2) most people start with the old well-known shitty tools and then they're
locked in... and the efforts required to move away just increase over time
(sadly, nobody got fired for choosing Jenkins in the first place :( )

~~~
jakecodes
> There is no room for gitlab. Teamcity already has a free edition offering 20
> projects and 3 slaves.

GitLab offers unlimited private projects, and unlimited runners for CI right
now.

~~~
user5994461
I find that worrying for the future of Gitlab.

It's really hard to charge money, especially against a truckload of both free
AND paid tools which do the job.

They decided to NOT charge money on the number of projects or the number of
runners. They've made a product with no incentive whatsoever to pay for it.

We could say it's great, we get get another free tool! but how are they going
to make this work on the long term?

They have no business model and the investor funds will eventually run out at
some point. Then, we'll be left with another free open source abandoned
projects, just like jenkins?

~~~
sanswork
Their business model is the enterprise edition which comes with better support
and newer "enterprisey" features first. It seems to be doing really well given
their comments here. Gitlab.com is a loss leader to get their potential users
excited about gitlab so they convince the potential buyers to pay for it.

~~~
wildfire
"enterprisey".

Perhaps I'm in the minority but I have actually setup my home system to use
SSO (backed via LDAP).

It annoys me no end that all these services seem to think that charging to
maintain my userbase is a way to get me to think they care.

What it means is it invariably the SSO support is barely tested and poorly
documented. For a number of products, I've tried out the "enterprise" version
and realised that their features (e.g. SSO, audit, etc.) are just not useful.

Largely because there are not enough people looking at the thing or attempting
to use it.

~~~
sytse
I think you'll be happy to hear that LDAP SSO is part of GitLab Community
Edition (CE). It is well tested and used by more than 10k organizations. For
more information please see [https://gitlab.com/gitlab-org/gitlab-
ce/blob/master/doc/admi...](https://gitlab.com/gitlab-org/gitlab-
ce/blob/master/doc/administration/auth/ldap.md)

Please note that LDAP group sync is part of Enterprise Edition, but I assume
your home system doesn't need that.

------
sandGorgon
Congrats guys! I'm curious if you are going to change directions in technology
- ruby is fairly unsuited for on-premise deployment.

Before I get flamed, of course you guys have made a great build and deployment
system... but nothing can beat a " java -jar start.jar" or "./golang" . And I
think it comes a fair bit of performance for free.

Wonder what are your thoughts around that ? I keep thinking that Gitlab could
be the "killer app" for a new fangled java framework like SparkJava or
something.

~~~
zegerjan
Ruby, compared to some compiled languages, is indeed harder to ship, which is
why we've got the gitlab-omnibus package.[1] Thanks to our packaging team the
install and getting GitLab up and running shouldn't take over 10 minutes.
Maybe not as easy as compile and run like Go offers, but I urge you to try it,
it is really simple.

Now, we use more and more Go within GitLab. For example, gitlab-workhorse[2]
and the gitlab runner[3] are written in it. But converting our main app,
gitlab-ce and gitlab-ee, to another framework and language would makes us
unable to ship new features for at least a year. Even when we would gradually
rewrite this would hurt our ability to consistently ship new great features.

Also, please don't forget that Ruby and Ruby on Rails are very mature, stable,
and so far have served us very well and I expect it will for the next years.

We might, as we've been doing for some time, let workhorse handle more compute
expensive operations, but again, other than that I don't see it happening any
time soon.

[1] [https://gitlab.com/gitlab-org/omnibus-gitlab](https://gitlab.com/gitlab-
org/omnibus-gitlab) [2] [https://gitlab.com/gitlab-org/gitlab-
workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) [3]
[https://gitlab.com/gitlab-org/gitlab-ci-multi-
runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner)

~~~
Singletoned
> converting our main app, gitlab-ce and gitlab-ee, to another framework and
> language would makes us unable to ship new features for at least a year

This would be quite a good argument for not tying oneself so deeply to a
particular framework.

~~~
matt4077
What?

How would a transition to go be easier if they had used ruby without rails?

------
agentgt
We would seriously consider GitLab if they supported Mercurial. I am so
annoyed with atlassian (another company that perhaps could pay attention more
to developers). I like git for OSS but we love hg for our internal projects.

~~~
jobvandervoort
It would severely hurt our velocity if we'd decided to support Mercurial,
whilst the benefit is only for a small group of potential users. We're not
planning to support hg.

Would a migration tool or something similar help?

~~~
alkonaut
A git migration tool would be terrific: I'm on a svn project with a 20Gb
history, 3Gb working copy, with TONS of versioned binary assets. The migration
story to git is a nightmare with lots of different tools and utilities that
reportedly do some part of the migration, but don't play well together.

I'd like to see a _simple_ conversion tool that lets me configure everything
(branch filters, user conversion, wildcards for what assets must go to LFS)
that lets me convert a repo in TFS/SVN/HG into git _with_ LFS.

The key here is integrated LFS. Without it, git is a complete no go for any
shops that does lots of large versioned binaries. Git+LFS still seems like
black magic to me, so it would be nice to see someone make a friendlier front
for it.

~~~
mi100hael
> Without it, git is a complete no go for any shops that does lots of large
> versioned binaries.

Git is source control. It's for versioning source, not binaries. Built
dependencies or artifacts or whatever else should be stored somewhere else
like FTP.

~~~
Stratoscope
For some of us, binaries _are_ source. For example, anyone developing in Unity
or Unreal Engine has large binary files that represent the game levels,
blueprints, and other assets. These aren't generated files, logically they are
source code that should be versioned along with the textual source code.

(Tip for Unity users: The very first thing to do when you start a project is
to go into the project settings and change it to Text Assets. That way the
scene files and such will be text instead of binary. It's still a fairly
opaque YAML format, but at least they will be more diffable.)

~~~
flukus
For every legitimate use of binaries in source control there are dozens of
idiots checking in build artifacts.

~~~
alkonaut
Build artifacts aren't necessary to bring over to git in a conversion from
hg/svn. I archive installers and other artifacts in svn, but if I moved to git
I'd just archive those somewhere else. The binaries that are actually part of
the build (a few binary dependencies, lots of graphics, test in/out data etc)
must be next to the source however because those are needed to reproduce a
build.

------
xxpor
Maybe I just haven't been following the news, but since when does Y Combinator
do Series B rounds? I thought they (you?) were exclusively seed funders.

~~~
1123581321
YC Continuity invests later-stage money: [https://blog.ycombinator.com/yc-
continuity-fund](https://blog.ycombinator.com/yc-continuity-fund)

------
meirelles
I've been using the GitLab Community Edition for about ~1 yr. It's an amazing
experience so far. Even the upgrade is really simple (just a apt-get
upgrade!). Best of luck to you guys.

~~~
theunquietone
Thank you! Happy you're enjoying GitLab CE

------
ShakataGaNai
GitLab has made a lot of great inroads and will continue to do so. It's all
about momentum. Of course people are going the tools that are familar to
themselves. However as more and more start to adopt GitLab (probably as a
github replacement or small personal projects), they are going to ask for that
more in the corporate world.

It's also a matter of developing the maturity of the integrated tools. CI for
a example. Does jenkins have a shit load more features? Yes. Does Jenkins do
scheduled tasks? Yes. But jenkins is also a massive ugly, unwieldy behemoth.
Some issues like the Cronjob portion can be worked around in GitLab (webcron
to build trigger APIs) but it's not as nice... yet. The CI feature is barely
an infant compared to the age of Jenkins. However for 90% of what I need?
Works great. Well worth it to me.

Every month they've been releasing improvements on numerous fronts and it's
been amazing to see. The product has gone from "eh" to "wow" in about a year.
I look forward to seeing if they can sustain this product growth (I'm guessing
the 20mil will help).

------
izolate
Congrats on the funding! Please hire (and learn to take seriously) a design
team.

~~~
YorickPeterse
We actually do employ several UX designers at the moment (see
[https://about.gitlab.com/team](https://about.gitlab.com/team)).

~~~
matt4077
You could spike their creativity with this simple command:

sudo echo "127.0.0.1 github.com" >> /etc/hosts

~~~
DeadBabyOrgasm
I think you mean:

echo "127.0.0.1 github.com" | sudo tee -a /etc/hosts > /dev/null

------
patleeman
I realized recently that gitlab offers github based auth and i've been using
it host my private repos.

I also use it at work and really like having the ci system built in.

~~~
theunquietone
Thanks! GitLab CI is getting better and better. Let us know if you have any
feedback.

------
nathan_f77
A few years ago I tried really, really hard to get an interview at GitHub,
because I had the same vision and wanted to see them expand into new products
like CI, and all the stuff that Gitlab is doing now.

Why has GitHub been so stagnant, even though they have so many employees?

~~~
connorshea
If you're still interested in working on these things there are lots of
positions open!
[https://about.gitlab.com/jobs/](https://about.gitlab.com/jobs/)

------
dksidana
It will be great if they add communication tool like slack/hipchat in their
master plan.

Reason, I am asking for this, it that I see such tools have critical to do
development these days. gitter has already shown initial success/value of
integrating with SCM.

~~~
kossae
They actually already offer a tight integration with Mattermost:
[https://gitlab.com/gitlab-org/gitlab-mattermost](https://gitlab.com/gitlab-
org/gitlab-mattermost)

~~~
dksidana
Agreed but looks like GitLab is trying to avoid integration route in favour of
building that component in the product itself.

~~~
sytse
We're not planning on building a chat client in GitLab. We think Mattermost is
awesome and it is part of our Omnibus package. We're working on better
chatops/chatbot integration with Cog [https://gitlab.com/gitlab-org/omnibus-
gitlab/issues/1412](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1412)

------
suchitpuri
Love gitlab, hopefully we will get more and more services start supporting
Gitlab now.

~~~
theunquietone
Thank you! We hope that too :)

------
GutenYe
I like the integration of the Continuous Integration, Continuous Deployment,
Continuous Delivery compares to GitHub.

~~~
theunquietone
Thank you! We're always trying to build great new tools that are helpful.

------
faragon
GitLab plan is "embrace, extend, and extinguish". And I hope they will fail on
that, and then, they'll start providing standard integration APIs for third
party.

~~~
sytse
Indeed our company strategy is modelled after MSFT. GitLab 9.0 will be renamed
XP and we already have a Vista team in place. They keep demanding a higher
expense budget to achieve a Ballmer peak, not sure what that is about.

Anyway, we want to make sure GitLab plays nice with others. there is an
extensive API
[https://docs.gitlab.com/ce/api/](https://docs.gitlab.com/ce/api/) and it
includes a commit status api to play well with other CI solutions. Please let
us know if there is anything missing in our standard integration APIs for
third parties.

~~~
connorshea
Skip GitLab 9.0 and go right to 10 :)

------
weitzj
Gitlab sounds better day after day. Still we are doing github, Jenkins and AWS
ECR (as a container registry Just a quick idea of mine was:"So github is
pretty centralized right now,so is gitlab as well.But I can run gitlab on my
own machine. So would it be possible for gitlab to offer a sync service,where
I could sync my gitlab server with gitlabs' server? " So if gitlab(github) is
down I can ~~let~~ rely on my local copy?

~~~
sytse
You can use
[https://docs.gitlab.com/ee/workflow/repository_mirroring.htm...](https://docs.gitlab.com/ee/workflow/repository_mirroring.html)
for this (EE/.com only)

~~~
DeadBabyOrgasm
Part of the discussion for the downside of centralization on GitHub is that it
is also the issue tracker and wiki. Does GitLab offer mirroring for these
services too?

If I understand OP's question, it seems syncing would involve more than just
`git push` from the local gitlab server to remote.

~~~
weitzj
Yes. That was my question. Sorry.no native English speaker.

------
daveloyall
[https://youtu.be/KrF7jNfDSnI](https://youtu.be/KrF7jNfDSnI) <\--live, on air
now.

------
echelon
I'd pay the guy that has my github/twitter/gmail/hn username on GitLab $500 to
give it to me. I don't think he's actively using it, but I can't figure out
how to get in touch with him. :(

I really want to switch to GitLab given the focus on tooling and workflow.
_edit:_ and also your super nifty tanuki logo, which would make a hip vinyl
laptop sticker.

~~~
theunquietone
Hey there - we have a process for requesting usernames that aren't being used
actively.

[https://about.gitlab.com/handbook/support/#dormant-
usernames...](https://about.gitlab.com/handbook/support/#dormant-usernames-a-
namedormantusersa)

~~~
echelon
Awesome! Thanks! I knew that there was going to be some discussion about this,
but I hasn't seen the official policy yet.

> The account in question has no data.

Does this mean if the account has private repositories, even if unused /
dormant, that a username cannot be freed? (Understandable policy.)

In any case, should I file a ticket, email support, or wait for automatic
processes to kick in?

~~~
dblessing
> Does this mean if the account has private repositories, even if unused /
> dormant, that a username cannot be freed?

Correct. We understand that sometimes users will be dormant for a while and
when they have data of any kind, we have to give them the benefit of the
doubt.

Please send us an email at support at gitlab to start the process.

------
gargs
Just tried to set up the 2 factor authentication. Easy. But, would it be
possible to provide a phone number fallback? The set of printed codes is nice,
but the chances of losing them are far higher than losing your phone or having
to deal with a corrupt authenticator app.

~~~
marcc
I like that they aren't providing a phone number as a backup. There has been a
lot of discussion recently questioning SMS-based 2FA as a target for social
engineering (and other attacks).

[https://news.ycombinator.com/item?id=12163046](https://news.ycombinator.com/item?id=12163046)

~~~
sytse
Thanks. Phone number backups are hard to set up and there are concerns about
the security. That is why we have not build support for it. BTW I recommend
using 1password so that you don't have to reset 2FA when you move phones (like
with Google Authenticator).

~~~
snorremd
Another great alternative in the 2FA client space is Authy (free of charge).

------
oelmekki
Congratulations guys, it's well deserved :)

With the addition of trello like board, gitlab has come to a point where I
just can't name a new feature I would love to see in it. But then again, like
most, I would not have put so many things in it (good ol' unix philosophy) and
have been pleasantly surprised about how everything added just fit in.

My only deception about the announcement: after the teasing last week, I would
have expected more concrete features to be announced in the "master plan"
article (what's the next feature?), but well, I'll wait and see.

~~~
oelmekki
Btw, this is certainly not magic. Would love to hear about your dev / product
design tips to make something having so many features not being a bloated
software.

------
dflock
I don't see anything about Documentation in there? I would really like
something better than Confluence woven throughout. Is there something that I'm
missing?

~~~
connorshea
Wikis do exist, and you can always have a `docs` directory and then use GitLab
CI to package the docs up and/or deploy that directory as a static site.

We have this issue which I'm fairly fond of, though I'm not sure we'll ever
actually implement something like this: [https://gitlab.com/gitlab-org/gitlab-
ce/issues/17937](https://gitlab.com/gitlab-org/gitlab-ce/issues/17937)

------
jrowley
This is kind of off topic, but I hate that I cringe every time I read the
words "Master Plan". Hitler kind of ruined those words for me.

Did my UC Santa Cruz education do this to me or do others ever feel the same?

Edit: Congrats to Gitlab. I need to experiment with integrating an instance
with phabricator [0] at work.

[0] [https://www.phacility.com/](https://www.phacility.com/)

~~~
sytse
Please allow me to link to a obligatory XKCD to lighten the subject
[https://xkcd.com/261/](https://xkcd.com/261/)

The master plan reference is inspired by Elon Musk. We can't compare us or our
plans with him. But we're inspired that his master plans are public
[https://www.tesla.com/blog/master-plan-part-
deux](https://www.tesla.com/blog/master-plan-part-deux) just like ours.

Please let us know if there is anything we can do to help the integration.
Please know that GitLab EE has a remote sync
[https://about.gitlab.com/2016/05/10/feature-highlight-
push-t...](https://about.gitlab.com/2016/05/10/feature-highlight-push-to-
remote-repository/)

~~~
jrowley
Haha that XKCD was hilarious. I'm was totally surprised my comment even made
it through the spam filters. I was seriously considering spelling Hitler,
H*tler or something.

Yeah, I should setup pushing to a remote repo, that could be really helpful.
Phabricator can also be configured to push to remotes automatically I think.
Either way, thanks for the great product!

~~~
sytse
You're welcome!

------
ohstopitu
I'm really excited for this master plan. I would love to have a just one tool
to do most of the job (c9.io would be a better alternative to Koding btw). As
of now, Gitlab seems to come the closest when it comes to that vision.

That said, Issue Tracker and Issue Board could be developed further to be more
in line with Jira and Trello/clubhouse.io

Apart from that, I love gitlab and keep up the great work!

~~~
jobvandervoort
Thanks! We see lots of improvements all around and welcome any specific
feedback / requests!

I can already spoil that we're working on many improvements for Issues and
Issue Boards.

------
uitgewis
Anyone know why GitLab insists on "Merge Requests", while BitBucket, Github &
others have "Pull Requests"?

~~~
shasheene
From [1]:

> Tools such as GitHub and Bitbucket choose the name pull request since the
> first manual action would be to pull the feature branch. Tools such as
> GitLab and Gitorious choose the name merge request since that is the final
> action that is requested of the assignee

I think GitLab are right to choose 'merge request', it has an immediately
obvious meaning compared to 'pull request'

[1] [https://about.gitlab.com/2014/09/29/gitlab-
flow/](https://about.gitlab.com/2014/09/29/gitlab-flow/)

------
napsterbr
GL seems great and I'm glad it's evolving. About a year ago I tried GL and it
was painfully slow. This was the main reason I chose Phabricator. Have there
been any progress on this performance issue? I acknowledge I'm quite outdated
here.

~~~
Keats
We moved to gitlab a couple of months ago (the public one) and it's really
slow so we are thinking of having gitlab only for CI and do everything else on
github.

~~~
sytse
GitLab.com can be slow, sorry for this, We're working on it in
[https://gitlab.com/gitlab-
com/infrastructure/issues/59](https://gitlab.com/gitlab-
com/infrastructure/issues/59) and [https://gitlab.com/gitlab-org/gitlab-
ce/issues?scope=all&sta...](https://gitlab.com/gitlab-org/gitlab-
ce/issues?scope=all&state=opened&utf8=%E2%9C%93&label_name%5B%5D=Performance)
and in the infrastructure on to make our infra faster
[https://gitlab.com/gitlab-
com/infrastructure/issues?scope=al...](https://gitlab.com/gitlab-
com/infrastructure/issues?scope=all&state=opened&utf8=%E2%9C%93&label_name%5B%5D=performance)

------
radicalbyte
Nice to see it's going well. One thing that interests me as an NL-based
entrepreneur (well, technically a freelancer for now): are you guys still
based in Utrecht or did you have to move to the Valley in order to profit from
the investment scene?

~~~
Snappy
GitLab is a remote-only company, so really, we're EVERYWHERE! There's still a
NL entity, but now there's a US entity, and maybe more countries coming.

I can't comment whether Sid _had_ to move to the Valley to reach investors,
but it probably didn't hurt. That and YC.

~~~
sytse
During raising the A round I promised I would be in San Francisco the majority
of my time to spend time with customers, investors, partners, and press. Being
remote only allows me to travel back to the Netherlands 3 times a year for 3
weeks each apart from my vacation time.

------
bcjordan
Just started working on a sort of getting started mega blog post on
CI/CD/CT—is there anyone at GitLab who would be up to review once ready and
make sure I'm covering the GitLab offerings completely?

Can reach out at username at gmail!

~~~
sytse
Sure, please email community@ company domain for this, you can find this via
the bottom of
[https://about.gitlab.com/handbook/marketing/](https://about.gitlab.com/handbook/marketing/).

Of course we would be happy to host you as a guest post, please send a merge
request to [https://gitlab.com/gitlab-com/www-gitlab-
com/merge_requests](https://gitlab.com/gitlab-com/www-gitlab-
com/merge_requests)

------
erjjones
Does GitHub own any intellectual property that might require GitLab to
licensing? or did GitHub totally miss the intellectual property piece of the
puzzle?

~~~
sytse
Both are based on Git that is open source and trademarked by the Software
Freedom Conservancy.

------
tschellenbach
Github is great, I see no reason to switch. The competition should definitely
accelerate development though, so that's nice.

------
samblr
This is very exciting to hear - was so wishing github to go in this direction
all these years!

~~~
samblr
I migrated to gitlab - the joy of CI, CD, runners and Trello like boards - all
at one place has made my day.

------
arunc
I really wish they add mercurial support, albeit there seems to be no plan
currently.

------
snissn
Is gitlab profitable?

~~~
sytse
We're not profitable. We took investment to grow faster. Currently the
majority of our costs are covered by GitLab Enterprise Edition.

------
ChoHag
Why is a corporate fluff-piece the top story on HN?

~~~
pawadu
because

1\. github needs some competition

2\. gitlab hosts f-droid and some other awesome projects

3\. many of us use their enterprise edition at work (and loving it)

4\. they were funded by the very company that runs this forum

~~~
ChoHag
Ah it's an advert from our corporate sponsors. Understood.

------
mariusz79
Is that Master Plan stuff a new fad?

Soon at a Hacker News near you:

Master Plan considered harmful.

