GitHub Universe 2018 - Scaling your business, 6 Nov 2018

Previous Meeting

⏯

youtube image

►

From YouTube: Moving from mono to multi: How Continental manages a distributed code base - GitHub Universe 2018

Description

Presented by Timm Drevensek, Software Architect (Continental Corporation).

When working on larger software projects—like autonomous driving or complex embedded controller logics—you’ll eventually need to decide how to organize your code base. Whether you choose multiple Git repositories or a mono repo, you’ll have to deal with both pros and cons. Even if it’s the cleaner solution from a configuration management perspective, the additional complexity of handling a multi-repository setup often rules it out.

About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.

For more information on GitHub Universe, check the website:
https://githubuniverse.com

A

♪ (music) ♪.

A

(Timm) hello and welcome to github universe.

A

My name is timm drevensek., I'm working for the continental corporation.

A

For my role,, I'm a software architect, or I'm a devop engineer.

A

And within this talk, I would like to share with you.

A

The work that we've done to switch from a mono repository setup to a multi repository setup.

A

So this is a talk about this topic.

A

The main question,, if you talk about mono or multi repository setup,,.

A

Is how do you put your code into this one.

A

so,, technically speaking, in git? You have always some kind of--.

A

Two kinds of where you store your data.: you can have-- on the left. Side--. You could have a single repository setup.

A

Or a mono repository setup,, where you put simply everything into one large code, base.

A

And, on the other side,, you have a multi repository setup, where you have just some kind of linkage, repositories--, so one main repository which is linking to your code, which is distributed over just a bunch of repositories.

A

If you now say, "okay,, this set up--, it's always some kind of to find the right solution for yourself.".

A

If you go for google and search, "what is the right solution for me?".

A

You will get tons of different advantages, disadvantages, on both setups.

A

So,, it's a bit.... You need to find a way which one is dealing for. You.

A

At our company, or at our project,, we started with the mono setup repository, and later on. We switched to multi repository setup because it was somehow required by our code--.

A

How we built code,, how we distribute software.

A

so,? We ended up in this multi repository setup.

A

What I'd like to show you today is how we worked with this one.

A

Because it's not so easy. we brought out a tooling.

A

Which is there for handling this? In the background.

A

So that it feels the same way with a single repository,.

A

As the same way, like you work with multi repository setups.,.

A

And this tool we just open-sourced a week ago, so on github.com you can download it,. You can run it by yourself,.

A

And work with the same kind, how we work with multi repository setups.

A

But,, let's get one step closer.

A

I'm here from continental, so you might think, "okay, it's a rubber company.. What does a rubber company have to do with software,.

A

And this kind of problem that I'm talking about?".

A

What you might know from continental is mainly tires.

A

So, tires, rubber--that is what you'll see in the commercials,.

A

That is what you might buy for your car.

A

But this is only the public available trend that is available to the world,.

A

Or what people buy or what people see in commercials and stuff like this.

A

But actually, we do more..

A

I just tried to get an overview on what components we do.

A

And we're manufacturing for the oem market, and after,, let's say, half an hour or so, searching through the internal pages,.

A

I just stopped because the page will not fit.

A

I think you can multiply this page by five.

A

≫From us, you can buy a high pressure pump for a car.

A

You can get a 48-volt generator., you can get a system for braking system.

A

We also do stuff like automated driving, or back-end services, which are connected to this kind of thing.

A

To summarize it somehow, I would say continental is--.

A

The only thing we don't do is we don't bend metal around these components and call it a car.

A

But for the rest,, the whole components we build are worldwide distributed.

A

The company itself is really spread around the world.

A

We have around about a quarter million employees worldwide.

A

At around about 500 locations.

A

If you go for more numbers,, we are the number two for tire tier one,,.

A

So distributing or providing our devices to an oem.

A

Which will build a car out of this one.

A

so, at the end,? I would bet that every one of you has used our products.

A

While driving a car.

A

For me, personally,, while the company does everything somehow--.

A

I'm from germany,.

A

In the middle of europe, and I'm working r&d.

A

Geographically,, I'm located really at the center of germany,.

A

Around frankfurt. there are two locations--, one is babenhausen,, one is wetzlar.

A

You've never heard, maybe, of these cities, before.

A

Wetzlar is mainly in infotainment-- so,. We do the classical way of radios, infotainment.

A

We do also navigation, systems., so,, technically speaking,.

A

What we are dealing with in the software perspective, is we're dealing with linux, we're dealing with android systems.

A

That we build up upon radios and navigation systems.

A

And on the other side,, the second location, I'm doing work travel to is babenhausen,.

A

Which is making cluster instruments.

A

so, cluster instruments is something where we try to prevent that. You run into a speed trap with these devices.

A

And inside these devices we deal mostly with real-time operating system,.

A

We deal with safety aspects that you need to pack into this product.

A

Until it hits the market., but we do also more stuff, like head-up, displays, interior camera systems, detecting how you behave and how you feel and drive the car itself.

A

So, back to my work., I'm currently working in a project where we really migrate, both systems to become one.

A

If you have a look at the past,, you will see that a speedometer was before a cluster instrument was before just mechanical stuff.

A

Which was showing how fast you drive., then the current way--, it's more like you, have mixture out of a full display system.

A

And something where some parts are still mechanically.

A

On the other side,, the multimedia part, was you have your navigation system on a cd,? Put it in, plug it? In,.

A

And then you have your navigation system.

A

today,. These systems are mostly bound to cloud environments.

A

And my work is that we migrate both systems into one product.

A

So, we get-- in the future. We will see more and more cars.

A

Driving with a single soc.

A

So, both devices are migrated into one device,.

A

Into one central processing unit., this brings some kind of complexity into the system.

A

Because now you have a system which is some kind of mixed safety.

A

You have from the multimedia it might crash,, but the speedometer should not crash.

A

so,. We have a mixed safety,. You have open source,, open partitions, where you can really get code, a website, and so on.

A

So,, the website should not be able to crash your cluster system.

A

So, we have a mixed safety system where we have virtualization,.

A

Different os's running on a single soc.

A

So,, this is some kind of the pre-story.

A

Now, the question is:: where does this take with the multi repository setup?.

A

Back to the introduction of my talk.

A

The issue which we ran into--.

A

The requirement to switch from a single to a multi-repository setup--.

A

That is somehow that we have a real wide spectrum of product variances.

A

This somehow brings us that we also have this interface problem.

A

And what we'd like to do on the other side is we'd like to have a distributed atomic operation on our code.

A

So,, when we make changes to our software for our devices,.

A

We would like to have this as an atomic operation.

A

Let's give a small example.: let's say you buy a new car.. What you do is you go to a website or to a dealer.

A

Then you start defining what kind of car you'd like to have.

A

You start with the engine.

A

next, you take the color of the car.

A

The third part might be: what features should your car include.

A

There might be that you add, for example, a parking system,.

A

Or park distance control.

A

It might be that you enrich the infotainment capacity of your car.

A

It might be that you add a drive assistance system to your car,.

A

Or a rear view camera. in this website configuration,, you click what you'd like to have,.

A

Send it up and some weeks, some months ago, you got a new car from your brand that you like.

A

But this kind brings us-- so, as a tier 1 manufacturing of device--.

A

Into some kind of problematic: how we need to deal with software inside this product.

A

You cannot simply say, "okay,. I will take a speedometer.

A

And put in the largest chip to get everything done.".

A

We cannot say, "okay,, we have a chip that can run rear view, camera,.

A

Infotainment system, assisted driving," into a budget car.

A

You simply cannot put a chip in which costs, maybe,.

A

$50-$100 or something like this, into a system where you don't have so much--.

A

What the oem cannot sell for a budget car.

A

This kind of configuration somehow leads that we have a [communicational] problem.

A

In our software, when we're manufacturing these devices.

A

For example,, you have an algorithm that is calculating the fuel state of a car.

A

The input parameters will depend on what car you buy.

A

If it's on the wheel, base-- so,, if you have a long or a short car--,.

A

The fuel tank will differ,, so the algorithm will differ also.

A

That you have inside the cluster instrument., the second might be if you've chosen a feature--.

A

For example, a rear view camera-- this will depend that you will require a different chip,.

A

Because not all chips--, I mean, when you just have a speedometer.

A

Which is showing the speed and the total kilometers,.

A

You might not have a video-in system, or a video-in processor to get in data from the rear view camera into this one.

A

So, at the end--, and one thing that I missed is that we are in embedded markets,.

A

So we deal with chips which have sometimes below 1 megabyte of size, also,.

A

Up to a system which has 2 gigabytes of size, for memory or for flash footprints.

A

Therefore,, to summarize it somehow,, the requirement is that we need to have a component-based model,.

A

Also in the embedded world, where we don't have a hundred layers of interfaces.

A

we're not in java world. people were doing assembly some years ago, and now we're back to hardcore c++ programming.

A

So,, our main problem, or our requirement is that we are in a way that we can reuse our code.

A

Around different projects or within a different line of products.

A

That we're generating., if you say-- okay, back to the main topic--.

A

Mono or multi repository--, if you go for mono repository,, that is easy to handle for everybody.

A

You have just one repository,, you check it out, and you have everything on your hard drive..

A

It always contains a consistent state,.

A

So that when you have one checked out, everything will be in there.

A

But the issue with this setup is: you cannot make some kind of components.

A

You cannot really make component reuse..

A

You cannot reuse one component within another project.

A

You cannot share code., and this is maybe not the right solution. If you really deal with large code bases.

A

And also one issue--, when you have embedded code,, you have really strong dependent, code,, no interface layers in between.

A

and on the second side, you have this multi repository setup.

A

Therefore, the problem with the component decoupling is solved.

A

One repository may contain the graphic subsystem,.

A

One other may contain the flash routines,.

A

Some contain the fuel algorithm that calculates the fuel.

A

So, this one is really there for splitting up your code, or a large code base, into multiple components., but someday. You will run into the problem that this one is not so easy to handle for the developer. Itself.

A

Because you don't have a unique state over this repository.

A

You check out the stuff,. You have different baselines.

A

so,, you don't have one master repository,, one masterline--!

A

You have ten, twenty, thirty different mainlines that you need to somehow harmonize.

A

There are some approaches: available, how to connect them.

A

One is, for example, sub modules, or google rapport,, which will provide you this kind of linkage, system,.

A

Saying, "okay,, this repository needs to be linked. Together,.

A

So sub-modules, or google rapport is tools that you might choose,.

A

And while the multi-repository setup is somehow strange to handle.

A

There is also something like sub-3 or yocto combo-layer.

A

Which will provide you a way that you have this multiple repository setup, and they simply merge it down to one large repository that you can exchange and share across..

A

But that is not somehow the right solution. They would like to have.

A

For example,, what you also have inside these multi repository setups.

A

Is the interface change problem.?

A

Let's say, today you have your setup with 20 different repositories,.

A

And you'd like to make a change, say, switching from python 2 to python 3.

A

So,, what will happen is you will nearly need to touch every line of code.

A

That you have inside your repositories.

A

and now how do you deliver this at once??

A

I mean, you can deliver each repository each by its own,.

A

But in between this delivery, there might be one time where you have an inconsistent state inside your repository setup.

A

I'd like to show you this one.

A

sub-repositories is supported in github.

A

so,. What you see on the upper left is that you have the super repository,.

A

Which is really some kind of connecting the other repositories.

A

So, you have two folders, which are pointing or referencing.

A

To some other repositories., the super repository is referencing. The documentation.

A

And the source repository.

A

So,, what I'd like to show you is how this is working--.

A

How we deal with this kind of stuff., first of all,, what you do is you put in a git module file.

A

Into your super repository, and inside the git modules you define, which folder should be referenced by which repository setup.

A

So, here the doc folder will be referenced by a test mega, merge, doc.git repository.

A

And the source folder will be referenced by a different sub repository.

A

Git will store this kind of linkage, here.

A

the ssh 1 key that is actually referencing inside this tree of the sub repository.

A

Will be stored in the git 3 object, itself.

A

so,. We won't see this here;. You will only see this while committing stuff.

A

So, how to work with this kind of stuff? Is you go here, and say, "okay,? I would like to add a readme file.".

A

So, you go the super repository, describing,. This is my super repository.

A

The same you can also do for the sub repositories.

A

You go to the sub repositories,. Add their file. Saying, "this is my documentation. Repository.".

A

And the third one is, for example, inside the source, repositories, saying.

A

"Okay,, this is my source repository.", and the interesting part is many of the ui tools support this kind of work. Flow,, because later on, I can say, "okay, I'd like to commit this stuff.".

A

So, here you don't do one commit,. You do three commits--.

A

One for the source, one for the doc, and one for the main repository--, the super repository.

A

And here what you see is it's not only the readme that was added,.

A

It is also the reference onto doc, and source repositories is adding.

A

So,, the ssh 1 referencing, the other repositories.

A

Will be added also. so then I can push the stuff, and everything's in master.

A

It works,, so that's why I'm standing here and telling you something about this one.

A

What is missing completely is the git workflow somehow.

A

And the tricky part here is why we are referencing an ssh 1 key,.

A

Out of the sub repository, and we have in the github world, we have this pull request. Workflow.

A

They don't fit together.

A

on the upper right. You have the super repository,, which is referencing to a sub repository by pointing in ssh 1.

A

So I say, "from the source repository. I want to check out on the location, src,.

A

The following content.", when I push this now to github's server,, what is happening, the input and the output of a pull request, will differ.

A

So,, whatever comes in is not the same as what is coming. Out.

A

The main issue with this one is that first,.

A

While the pull request is open,, the main line might change.

A

And the second one is the configuration of how the merge will behave.

A

Is not really clear, while you're opening the pull request.

A

So,, you could say the pull request should be closed while doing a merge,.

A

It should be closed while doing a rebase, or it should be closed while doing a squash--- squash every commit inside this pull request down to one.

A

So,, bringing changes to the mainline will change the ssh 1 key that we would like to reference from the other, from the super repository.

A

And there is somehow our dilemma that we need to solve. Here.

A

And we did this by providing an external solution,.

A

What we call mega merge, somehow, because we do multiple merges automated at the same time.

A

So,, our tooling, is nothing more or less than a github application,.

A

Which is instrumenting the organization,.

A

The pull request on the github server.

A

so,, what we did is we wrote an application based on ruby on rails.

A

We used the octokit framework for this one..

A

We packed it into a docker and we threw it down on a kubernetes cluster to run.

A

so,. What we do on the one side is.

A

We can create the look and feel and the behavior.

A

From the github perspective, as you were, dealing with just one repository,.

A

With a single repository,, but while you can do changes.

A

Which are distributed over multiple repositories.

A

And the interesting part here is when you see this little jenkins icon over there,, the ci does not need to know about anything that is happening. Inside.

A

So, there is no additional, external script matching that you need to add.

A

To check out the code that we have inside this construct.

A

We are only using github's module with a native operation on git,.

A

And we only use the github api and the github methods that are available.

A

The only thing that we do is we actually script. It.

A

And modify the stuff from the outside world..

A

Our application will work on api calls.

A

So we are instrumenting the github through the api calls,.

A

And when you say, "okay,, I'd like to create this kind of linked, pull request,.

A

Or connected pull request,, we will not create one pull request,. We will create multiple pull requests.

A

And link them internally, together.

A

on the same side we're using webhooks. So whenever something is happening,.

A

Inside this github with our connected pull request,.

A

We will affect, or we will trigger, actions that need to be done.

A

For example, updating one linkage between different sub repositories.

A

Last but not least,, one thing that is--.

A

While we use this api, we don't need to check out your code on the server.

A

There's no requirement that this mega merge tool.

A

We need to check out the whole repository-- which might be large;. I don't know,, 50, gigabytes or larger--.

A

So we don't need to do this.. Everything is done on the github server, and we're only calling different rest api calls on this one.

A

So, for the outside world,, if you're a ci system or developer,, we have the same kind of methodology,. We have the same kind of use and feel.

A

Like you are dealing with a mono repository.

A

so,, if you see on the upper left,, you will see the mainline is still there.

A

For a mono repository, you have the mainline., and what you also have is a jenkins that is building a pull request.

A

So, github provides this kind of pull request. Branch.

A

While you create a pull request, you might do your changes,.

A

And then what the server will do,, it will generate you, some kind of hidden branch,.

A

Which is a pull request, branch,, which will contain the actual merge of both the mainline and your feature? Branch down to one pull request: branch.

A

And this methodology we are using in multi repository setup in the same way.

A

So, here also, the developer will see version 1 and version 2 on the mainline,.

A

And the jenkins that is building this stuff will get the pull request: branches in between.

A

So while they didn't hit the mainline,, you will still see what is going on.

A

So you don't need any additional changes in your ci infrastructure.

A

You can just pull on the pull request branch of the super repository, and what you will get is you will get references to the sub repository.

A

Which are also inside the pull request, state.

A

Okay, I'd like to show you three parts how this is done.

A

First, should be covered how to make commits, how to create a pull request, and the third one, how to merge the stuff., because this, somehow, a bit differs.

A

So, the first step is,, let's say you have a change.

A

Which is now distributed over three repositories.

A

One change is in a super repository, and the other two changes are in sub repositories--, so under source and under doc..

A

Let's see how this looks when it's connected.

A

First of all,, I start with a jenkins file.

A

so, in my super repository,. I will create a jenkins file.

A

Which is there for ci automatization for us.

A

So we have this really easy, or very simple, one.

A

You have a pipeline with a single step.

A

and in this step, I'm referencing, now a run script,.

A

Which is not part of the super repository,, but which is part of a sub repository.

A

so,, I'm dialing into [ cd, ./src ] and then call a run script.

A

So, this run script itself,, which will be generated now-- make it executable--.

A

Will do also a simple operation; will simply cut out the output,.

A

But not from its own repository, but from the docked repository.

A

So,, what we're doing now is we are linking three repositories: together--.

A

Super repository, source repository, and documentation repository.. What will happen is this should be outputted.

A

and to make this happen,. What you do is create a branch for every repository--.

A

Not on the master;, you don't push on master..

A

We simply push on the universe branch for this example..

A

You could also do this with forks. our methods work for forks in the same way as it works.

A

For adding branches.

A

So, you create these branches,. You commit your stuff to these branches, and you push it to the server.

A

so,. What you will have now in the first step, is simply something that is disconnected. so,. You have three changes on three branches, somewhere on the github server.

A

A

So,, the next step is now how you connect this stuff--.

A

How to make a pull request. the usual way is to push your stuff onto one branch,, push it to the github server, say, "create, a pull request.".

A

This one is now done with a different tooling.

A

so,. You don't create a pull request in our example, with a github interface.

A

You create a pull request with a mega, merge, tooling.

A

so,. You go to this website and say, "okay, I'd like to create a pull request.

A

Include the following three changes.

A

and build me something as unique as an atomic operation.".

A

So,, what the tool will do in the background--, it will create you three different pull requests..

A

It will create a pull request on the source, repository.

A

Second, it will create a pull request on the doc repository,.

A

Which might also include code review--.

A

To make a review until your feature, branch hits the mainline.

A

It will create a pull request on the source and doc, in the first step,.

A

And then it will link the pull request, branch.

A

To the master, to the super repository.

A

So,, we are not referencing, something that was there before.

A

Inside this super repository, inside the sub module configuration,.

A

We will enter the ssh 1 key,.

A

Which is the temporary output of the pull request.

A

So,, this solution is then temporary.

A

It is inside the system-- super repository, pull request, referencing a pull request.

A

From a different sub repository.

A

And the advantage of this feature is that whenever I have a ci system.

A

Pulling on this pull request and trying to build this one,.

A

It just works, yeah?, it's the same way as you have--. A single repository would behave the same way.. It will check out this temporary branch and it will build this stuff.

A

Back to a video of how this looks., this is an application that we have..

A

We run it on a server,, so the user will connect to this one,.

A

Go through this, "I am github application.. I would like to authorize stuff.".

A

The next step, is, "I, can see the organization.".

A

We didn't use it here,, but you can select now the super repository.

A

So, you're selecting the super repository where everything's connected to.

A

Select the branch--, so here the universe, branch.

A

and the next step is you connect the sub repositories.

A

To this super repository merge., it's simply by selecting these sub repositories,.

A

Saying, "okay,, which branch are my changes on,, and where would I like to change this one." so, for universe to master. and then the moment I hit the "save and update",.

A

The system will go there, contact, the github server.

A

And say, "please do the following for me:: create the sub repository merges,.

A

Update the ssh 1 in the main repository,.

A

And we're done. and what happens now is that the ci system that was included here.

A

Will do what it should do., it will build the stuff and it will output.

A

So here the jenkins file goes to src, calls the run script,.

A

And dumps out our graphics.

A

So far so good., but what happens now, if you change your code;, if you'd like to modify different stuff?

A

if you're in the pull request, what might happen is, always like you, push something and it says, "it doesn't work. This way.

A

I need to modify my stuff,. I need to change what I have.

A

Inside the repositories., I need to make a patch for this one.".

A

So, here we are back, and this is still working the same way as before.

A

So,, you simply go to the doc repository and create a patch.

A

You push a patch onto the doc, repository, modify something,, and what will happen is the pull request will be updated,.

A

And in the moment that you update or in the moment that the server will update the pull request,, we will catch this event..

A

So we don't actually listen only for push and pull request. Changes,.

A

We listen to all kinds of events.

A

whenever there's an update,, the mega merge will wait for this one,.

A

See, "okay,, this repository is linked to the following super repository,".

A

And it will enter the newly generated ssh 1 key.

A

Into the super repository referencing, this one.

A

And then jenkins will go and build the stuff.

A

The same example here. you have the original documentation, file.

A

You say, "okay,, I add here a horse, and I would like to push this change.".

A

So, I'm pushing this change only to the doc repository,, so only the doc will be updated.

A

push it to the server.

A

and just a second later, or ten seconds. Later,.

A

What will happen is that the mega merge will update the referencing.

A

Of the super repository now to the new change,.

A

And there is a change., it's back on the pull request, or on this connected pull request.

A

And now, back to the last of the three parts.

A

We have committed something., we have created a pull request;. We made a change on this pull request.

A

And now the last step is really how to bring this change to the mainline.

A

Therefore, we also-- there is an internal way of how to deal with this one-- is we react on any updates.

A

So, for example,, we react on the state saying,.

A

"Is this pull request, mergeable or not?", and we say when there is any change. Pending--.

A

So, not on the super repository, but is there a code review pending.

A

On one of the sub repositories--, we will listen to the events coming from this repository.

A

And whenever there is a review done,, it could be merged.

A

We will update the super repository, or we will just wait until everything is done.

A

So,, when I have the first feature, branch,, which is, okay, our review, done--.

A

Nothing much changed--, but when I touched the second sub repository,.

A

Then my state somehow gets reviewed.

A

So,, whatever I have as preventing us.

A

From merging this atomic change to the mainline is now done.

A

Everything is green--. Code review was done on one sub repository.

A

Code review was done on a second sub repository.

A

So, in this moment,, what we do--.

A

The automatism will start merging the sub repositories.

A

Down to the mainline., so this is actually the first time that any change of you,, which you have pushed to pull request,, will actually hit the mainline and be publicly available.

A

And in the second or in the same time, frame,.

A

While we first start merging the sub repository content to the mainline,.

A

We will do the same again--. We will update our super repository here,.

A

Enter now the final ssh 1 key., so whatever might be there--, it might be squashed,, it might be merged,.

A

It might be rebased--. The output of the final commits will now be integrated in the sub module configuration of the super repository.

A

And the last step is merge. The mainline,.

A

Or merge the pull request of the super repository down to the mainline of the super repository., and that is the point where we really have done this atomic operation.

A

And delivered out to other people.

A

A

A

Getting back to video, how this looks.

A

so,, what we do is we have some kind of linkage.

A

Inside the description that we're automatically generating.

A

so, for the sub repositories, I say, "okay, simply approve;. Everything is fine,.

A

Documentation is fine." and also the source code looks fine for me.

A

so, approve it, and now is the moment that the system, you see, merged--.

A

So it will automatically start merging the stuff and bring it to the mainline. so, at the end,. What we have-- super repository is merged,.

A

Referencing, the output of the sub repositories, and we have a consistent state that was delivered.

A

So, at this moment, really, it is that you can switch now.

A

The reference from 1.0 to 2.0.

A

There is no time that we ever touched the mainline.

A

Or the baseline in between this.. So while you start this operation- and you end this operation, there is nothing that hits really the mainline that might corrupt.

A

Because one interface change might be different depending on other sub repositories.

A

The output is quite simple.

A

at the end, we're somewhere back at the start of my talk.

A

We are in one super repository, referencing to sub repositories, itself.

A

So, as a conclusion,, we have created a tooling that extends the github pull requests.

A

For handling multi sub repositories, sub modules.

A

This solution acts as an add-on..

A

It only requires git, and github features,, so no additional checkout, behaviors, script, whatever, comes after the pull request to merge is in between.

A

And also to merge this final state.

A

We don't need any additional database.

A

So,, we don't need anything stored in a mysql or so.

A

We store everything inside the github, pull request, description, somehow.

A

You can put there hidden marks, so everything stays inside this configuration.

A

For us,, we see this as a proof of concept, because it was the first time that we were able to make use.

A

Of the pull request mechanism that is inside github,.

A

And also make use of the git, modules, or git configurations--.

A

The git core itself--, without touching any additional stuff.

A

So, from our perspective,, hopefully something will come in github.

A

Somewhere in the future, and therefore we open source this stuff under apache tool, license.

A

You can go there,, you can check it out,. You can fork it,.

A

And you could also provide us some pull requests for this one.

A

Thank you very much., (applause).

A

♪ (music) ♪.