GitHub Git Merge 2016, 16 Nov 2016

Previous Meeting

⏯

youtube image

►

From YouTube: Version Controlled CI and CD, Sytse "Sid" Sijbrandij - Git Merge 2016

Description

Now is the time to bring the collaborative DVCS workflow to your deployments. This talk walks you through the essential steps of making the collaborative DVCS workflow a reality at your company, and then discusses the strategies GitLab utilizes to make the most of this process.

Sid saw the first ruby code in 2007 and loved it, so he learned to program and made this his profession. Previously, he engaged in various businesses, from selling programmable infrared receivers to starting a recreational submarine company. He is always looking to publicly document answers and make processes more efficient.

About Git Merge:
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content, user case studies and training workshops for Git users of all levels.

Visit: http://git-merge.com/

A

Thank you Chris for that introduction, and thanks to github for organizing this conference, I think they're doing a wonderful job. Give it up. Please people.

A

I'd like to talk about version control, see I and CD as a developer. You have many environments in which you work. You work in development. Obviously you have your test that run in continuous integration and you have your production environment, continuous deployment delivery.

A

What makes it all work and what might ease is today is that these environments need a compatible version control, workflow, first I'm, going to show that currently, even if you use the state of art the best things that are around your kind of bound to use incompatible formats to define your environments for in this way, so for development, suppose your top notch, you use a browser, ide called coding. Then this is a stack file that you use to define your development environment.

A

You specify that you want to boot up an instance on Amazon Web Services, you give it some variables. You say exactly what you want to do what you want to install. So this is the stack file for development, then for CI you could use something like get lab. Ciidamo get lab comes with a complete CI environment and, if you add this file, it will start running your tests at the top. You can define a docker container that you want to use.

A

You can also define some odd services that you want to use that you need to run your tests like a database. The fine casting has scripts that provision your environment. This is how you could could do it see I environment and then to deploy to production. Suppose you use cout Benitez. This is a coup. Bonita siamo found define how many replicas of your application you want. So you have some redundancy. You define what kind of containers where the ports are, etc. I thought I hope you see that all these examples were really different and I.

A

Don't think. That's the future. I think the future is that we'll use the same format and that well, it will be easier to unite these different environments and I think that format will be used on container images and with a container scheduler containers are like lightweight virtual machines. Contain your images, define what is inside the machine. The software that's loaded on there and a container scheduler you can think of it as something that provisions all the different containers and that make sure that there are enough if your load increases you'll get more containers.

A

If you need to so go somewhere else, it will move the containers for you, so you can take a note offline to do maintenance on it. Examples of container schedulers are Cuban. It is Apache, may sauce and docker swarm and I'll try to show that what I think is the future that will use these technologies in all our environments, for the development environments and all the other ones, I think, will base it on a docker file.

A

So most of you probably are aware what containers are I think that every time you push an update to your darker file, your your version control should make a new container for you and add it added to the diversion control registry.

A

There's one problem and we thought about doing something: well, if you push a new container, you pushing your docker file, we run a CI job and add that container you to your build artifacts build artifacts our way to store a binary you've generated, but a container is not quite like your average executable, because containers have different layers. Every time you run a commanding your doctor file, it will sort it as a new layers and these layers build upon themselves.

A

If we would just use build, artifacts we'd lose all that information and any time you make a small modification to your container you'd have to upload the whole binary again. This is less than ideal and not performance.

A

So I think that the future is that gatehouse should also be container registries. Not only do this store your source go, but they also store your containers, and this makes something interesting possible, because what you want is one docker file for all your environments, so what you could think of suppose I have a docker file. It creates multiple layers, I first built a docker file so that it is ideal for production.

A

But, for example, I used to be a Ruby programmer and in Ruby, if you want your development environment, you want some additional gems gems that you have to bundle in. That will end up in your container image, creating a different container image and it's not I can't leave those I want to I can't leave those dams out for development, but I don't want them include it in production because they might cause things to break.

A

What you could do in your dacha file is first make it provision for production. So that's the third layer here, the CD layer, I first make a docker image. That's ready for production, then in the additional lines of the docker file, I specify something that's fit for testing, see I and then in the last few lines of the docker file. Again re bundle, add new jams and make it compatible for development.

A

This way, I can have one container image for my project, but for my production, environment, I deployed a third layer and for my development, I environment I deploy my fifth layer.

A

So that the idea is that not only with your environments work with containing images, they should also work with a container scheduler and I want to describe how that would look for deaf, CI and CD for deaf.

A

It doesn't make sense to run a complete like KU Benitez instance on your macbook will probably not be very performant, so the people from red strap make something called local cube that you can run locally, but that's API compatible and from Asus there's Minnie May sauce, which, as far as I understand this quite the same thing for your CI environment.

A

You want to contain your scheduler that goes up and down with your workload. Right now contain your schedulers. Can provision more and less containers, but what it can do is have more or less instances, so they cannot request an extra virtual machine for you and what we saw at good lab testing our own stuff is that our load varies dramatically. Normally, it are just a few containers that are running, but sometimes it Peaks to over 100 instances.

A

So we created something called get LeBron or Auto scale that uses docker machine as a driver to automatically provision. Wherever you want more containers, you can use it with OpenStack. We use it with digital ocean to automatically request more virtual machines as as our load increases and then, when the testing is done, they're automatically deprecated.

A

This has worked very well for us, so I'm happy to announce here on stage today a few hours ago. We an enabled this for get lab calm right now. If you want to run your tests on get lab calm, you get free, see I with free, auto provisioning of your containers, and we think this is a. This is a great way to to make sure. Yet your demand is met and you're not paying more than necessary.

A

Lastly, we continues delivery.

A

On our most recent gitlab version, we had something that's called deploy to qu Vanitas. It again uses the red strat things and it allows you to go directly from get lab to KU benitez without any scripts. So we want to get rid of all those deploy scripts that are brittle and sometimes break and replace them with something where you're versioning is aware of your production environment.

A

One interesting thought is that we have the concept of branches and get wouldn't it be nice to automatically e-baby test every Bunch. So, instead of having a merge button, I have a button that says, merge if better and it gets automatically tested a be tested and only then deployed I hope I show that there is a way to have a a workflow that uses versioning to have more compatibility between development, CI and CD, and I look forward to talking with you after the later tonight, and maybe at the party responsered about these ideas. Thank.

A