GitLab Tutorial - Part 1 - Your Own Private GitHub

Hi this is Chris from CodeReviewVideos and in this video we're going to be looking at how we can install GitLab on an Ubuntu server

So in this video I'm installing GitLab on an Ubuntu virtual machine running inside Oracle's VirtualBox

but it doesn't really matter whether the machine's virtual or physical, the installation process is exactly the same

and just for reference I have one running on DigitalOcean and also a client one running on Linode

and they all work exactly the same. As long as you've got at least a gig of memory in them

that's about the bare minimum. And if you go at a gig, honestly

you're going to have to play with the swap file, which I'll cover in the show notes. But aside from that, if you're working

so if it's like your personal projects that you're storing, then effectively one gig, in my opinion

is going to be more than enough. But you can take a look at the links

as I say in the show notes, which will give you a slightly better idea as to the sort of RAM spec and the CPU spec etc if you're going to be using it

for a larger team. So as you can see we're installing the GitLab Omnibus

package and we're using the 7.10.1 release. Now thankfully since I put on

7 onto a DigitalOcean droplet and the installation process was quite involved you had to install various different pieces separately and so on but in the 7 release as you see in this video it really simple

It's almost like a one-liner. So, yeah, it's really not that difficult to get started with it

And essentially, the whole purpose of having a GitLab server running is so that you can store your own project

So you get the equivalent of having GitHub's functionality, but you've got it private and the benefits of doing that in my opinion are if you don't want

your code to be put in the hands of some faceless company not not saying necessarily a bad company

but i don't want my sort of intellectual property and as some of my clients see it the same way they

don't want the code that runs their business put out on like bitbucket or github regardless of

whether you're paying for that it's still in someone else's hands so worst case they could

take what you've done. It's kind of like tinfoil hat kind of stuff but at the same time

you do have to kind of take heed of the security implications of putting your

business critical code that runs your business then putting it on someone else's

servers is kind of crazy but the whole point really of GitLab is to bring all the functionality of having like GitHub or Bitbucket or whatever and putting that into a machine that you control

And really setting it up and managing it is not that difficult at all, but it's probably one of those things that seems a little bit more scary than it really is until you give it a shot

And so hopefully you'll see that, you know, within five minutes of watching this video, you could have a perfectly working GitLab instance

and in my opinion, GitLab is brilliant. So what you see in the background here now

is setting up the user account, the first user account that you set up. So you've got to change it

from that five life password that you get. And then once you log in, you can basically go about as though you would

as I say, you had your own GitHub running locally. As you can see in 7.10, I think

I'm not too sure if this came between 7.6 or 7.10, but after upgrading to 7.10

you can now import projects from GitHub and Bitbucket and whatnot. so there really is no excuse to not bring across your code base

What we're doing here is bringing in the SSH key from my laptop

and that will mean so that when you're pushing your code up you're not having to type passwords in or whatever

And then once we've set up this SSH key section we going to then set up our first project and add it as a remote like we normally would do if we were using GitHub or bitbucket or whatever the process doesn change it just the path that we pushing off the code to um will obviously not be one of those services it will be something that we control and there a

couple of little changes that they're going to catch me out here as you'll see but um yeah the

general gist of what we're doing is very similar to any of the other managed services so i've left

this sort of mistake in here well i say sort of mistake it was a mistake as you can see i've added

that in and even that is is wrong um you can see there it's going off to ubuntu master but i want

to show this piece anyway so that if you edit the .git slash config you can go in there and change

up the url of your remote the reason that i'm leaving that in is for two reasons the first it

was difficult to edit that out without making it look like well without having to start again

But the second thing is, if you're moving from, say, GitHub or whatever

and you want to move to using a GitLab, then changing that is as simple as just changing that one line in your config

And so, yeah, it's pretty straightforward to actually make a migration across

And as you'll see later on in this series, we can use all the continuous integration setups and stuff

and GitLab's got its own GitLab CI, which we will be covering. It's very, very cool, honestly