
From Kubernetes to a complete application development tool [video] - sytse
https://about.gitlab.com/2016/11/14/idea-to-production/?
======
dcgoss
Very often on HN I see links describing the latest and greatest GitLab
feature. It really seems like they've been working hard and doing a good job,
and they seem to have a clear vision ("master plan", in their terms). Where is
GitHub in all of this? Aren't they concerned about being outinnovated?

~~~
Untit1ed
Github is so ubiquitous that they can't afford to move fast and break things
like Gitlab can - another team at work considered moving to Gitlab to use all
these new features, found bugs everywhere and eventually went back to Github.

~~~
Perihelion
Thanks for the feedback -- it sucks that they found so many bugs in the
product. Any chance you remember what specifically they ran into?

~~~
Untit1ed
Mainly intermittent errors clicking around the interface, particularly 404s
when clicking on files that existed - they're not sure whether that was a
problem in the web interface or the files actually temporarily went missing.

~~~
sytse
That sounds more like a problem in the installation than a bug in GitLab. Was
this self-hosted or on GitLab.com?

------
sytse
I'm very excited about this. Especially about the terminal we show at
[https://www.youtube.com/watch?v=a7OIQfOJO-0&t=7m11s](https://www.youtube.com/watch?v=a7OIQfOJO-0&t=7m11s)
AMA

~~~
nstart
Super quick one. One of the things I'm working on at work is a staging env per
branch system. We use k8s too. Biggest consideration here is individual
environment variables per branch.

Eg. For testing we have a separate db to work on so we have test data and a db
where we can perform migrations if needed. Another example would be adding a
new feature that requires a different env variable for another api key.

Curious how or if these features support it. Super sorry if it's in the docs.
Since you were doing ama I thought I might ask it here :)

~~~
sytse
We're not doing environment variables per environment yet but we would love
to, see [https://gitlab.com/gitlab-org/gitlab-
ce/issues/20367](https://gitlab.com/gitlab-org/gitlab-ce/issues/20367)

------
no_protocol
This video is really neat and it seems like the promised plan is almost done.

Can you clarify at all what the plan is for supporting other container manager
systems? I looked at Openshift and it doesn't look like something you can run
on your own hardware. Maybe I am misunderstanding this though.

\--

EDIT: I had spent my time looking at openshift.com and didn't notice that
there is an open source version located at openshift.org. Sorry for the
confusion.

\--

I'm interested in using all the functionality shown in the video, but for a
small team and on our own hardware. Maybe it doesn't make sense that way, any
clarification would help!

~~~
sytse
Thanks for your kind words. We would love supporting other container
management systems. From the OP: "We believe container schedulers such as
Kubernetes are the future of application lifecycle management and are working
on Mesosphere support. We would love it if people would contribute support for
other container schedulers such as Docker Swarm and for other Kubernetes
providers such as Tectonic."

In the demo we use our own Openshift Origin installation on our own cloud
servers, for more information please see
[https://www.openshift.org/](https://www.openshift.org/)

~~~
no_protocol
> In the demo we use our own Openshift Origin

Thank you so much. I had spent 20 minutes this afternoon on openshift.com and
was looking for an open source version and just failed to find it. Sorry for
causing confusion with my earlier post.

~~~
sytse
No problem, at GitLab we used to have a seperate .org and .com site but we
noticed it caused duplicate content and confusion so we consolidated under
.com

Although great companies like Wordpress are doing a good job making it work.

------
gtaylor
I've got a gitlab-ce helm chart in review in the helm charts repo:
[https://github.com/kubernetes/charts/pull/202](https://github.com/kubernetes/charts/pull/202)

While it's still in the process of working towards a merge, it will make for a
very easy installation process:
[https://github.com/gtaylor/charts/blob/gitlab-
ce/stable/gitl...](https://github.com/gtaylor/charts/blob/gitlab-
ce/stable/gitlab-ce/README.md)

This is probably most interesting to those who don't want to use OpenShift.
There's some more fleshing out to do re: CI runners, but the basics are there.

~~~
sytse
Cool to see this progressing!

------
nathan_f77
What's the minimum monthly cost for running this setup? Can it be done on a
single server? If the minimum setup requires a lot of redundancy, then I think
this will still be a blocker for many side projects and small startups.

Does gitlab.com offer hosting for containers?

~~~
jobvandervoort
I can't comment on the monthly cost. You should be able to run everything on a
single server, but I suspect that if everything is under load, that would need
to be a decent server.

You can use our Docker registry on GitLab.com for free.

------
kemenaran
I wasn't sure what to thing about Cycle Analytics, and the metrics it provides
("time from thoughts to issue", "time from issue to code", "time spent
reviewing"). IMHO these numbers may be too synthetic to give meaningful
information. Plus, once we have this kind of dashboard, there is a risk of
starting to optimize for the numbers (instead of optimizing the reality
underneath).

That said, I see with this demo how these metrics could be useful to track,
well, when reviews are taking too much time (needs more people? better
repartition of reviewers?) – or when maintenance tasks are slowing new
features (needs better tests? more maintainers?). I guess I'll have to try
this out :)

~~~
sytse
For more detail about the numbers see
[https://gitlab.com/help/user/project/cycle_analytics#how-
the...](https://gitlab.com/help/user/project/cycle_analytics#how-the-data-is-
measured)

Do you mean that number are to coarse to indicate a specific problem?

Of course there is the problem of gaming the numbers. But we do think that
compared to many other ways of measuring productivity (for example the number
of issues solved) this is relatively robust against manipulation. Getting
something out sooner is better most of the time.

But thanks for the thoughts and I hope you try it out soon.

~~~
jacques_chester
> _relatively robust against manipulation_

My own view is that robustness to manipulation can't come from metric design,
it can only come from culture.

If metrics are tied to reward or punishment, then no matter _how_ clever they
are, they will be gamed.

~~~
sytse
I agree that everything will be gamed and that culture is the best protection.
I do think that some metrics are easier to manipulate (cyclomatic complexity
comes to mind) and some metrics don't correspond with effectiveness (lines of
code written).

------
wmf
What is OpenShift providing here that isn't in upstream Kubernetes?

~~~
sytse
Nothing, we just had to pick a quick way to install it and Openshift looked
nice. All the features are intended to work with all Kubernetes installations
down the road.

------
Nux
That looks pretty darn neat!

As a sysadmin though, I do wonder how maintainable and especially upgradable
is that thing without breaking half the world.

~~~
jobvandervoort
We release all of GitLabs components at the same time, guaranteeing that they
work together. Every month on the 22nd. Updating GitLab is no more work than
'apt-get install'.

~~~
Nux
That's great. I was referring to the whole stack.

Should I upgrade all my hosts, docker, kubernetes, openshift, gitlab,
mattermost ... what would be the chances of something to break to the point of
ruining my day/week.

Not everything is merely "apt-get upgrade"-able alas.

------
dmourati
The paragraph on "move to the left" does not make any sense to me.

~~~
sytse
I'm sorry to hear that. I should have probably included a drawing. Can others
maybe paraphrase what they think it means or does it not make sense to anyone?

~~~
wmf
You're saying that people used to edit locally, build locally, test locally,
_then_ upload to staging/the cloud; now you upload to the cloud first, then
build/test/etc. (Of course, people did it this way with Heroku for years
because it was harder to build locally, then the pendulum swung back with
Docker...)

~~~
sytse
Exactly, thanks!

