Now that we have our superuser all set up, let’s get our application installed onto our server. Or, more accurately, let’s get our application’s Develop branch merged into the Master branch in Git, and then use that to deploy to our production server. I’ll note quickly that if you’re running a more complex application, deploying directly from Git is probably not a spectacular way to go … you’d want to get into a setup that involves continuous integration, with testing at all stages, and then deploys to a staging server to be checked before going live.
But you’re not starting your own Dev Ops consultancy based strictly on these couple of server administration tutorials (please tell me you’re not doing that), so let’s keep it simple.
The best way to merge a branch to the Master branch is to create a pull request, and the easiest way to do that is through GitHub’s web interface. So, head on over to GitHub and navigate to your musiclist repo. I’m going to have to show you this using an example with only a few commits, because I’ve already merged my repo to Master so that it would be easier for visitors to follow the various updates. The principal will be the same, but if you’ve been reliably committing your changes on a regular basis, your commit list will be really long. That’s OK.
To get started, click the “Pull Requests” tab near the top of the page. You’ll see to the right a big green button that says “new pull request.” This button is calling out to you to click it, so go ahead and do so. You’ll be taken to a new page which allows you to compare branches, and this is where things get either mildly or majorly complex, depending on how complicated your repo is. Fortunately, ours is deeply uncomplicated, with only a single user working on it, and only a single branch to compare.
Click the dropdown box on the right side and choose your “Develop” branch. You’ll be taken to a new page showing the differences between Master and Develop. For most of you, this will be a possibly overwhelming amount of stuff! After all, we haven’t merged to Master since the start of this tutorial, and we’ve added a whole lotta code since then. Don’t get too freaked out, though.
The important thing is to check the grey bar up near the top, with the two dropdowns. It should say “Able to merge” in green text, with a green checkmark. That means the system is capable of handling the merge itself without needing human intervention. This should be the case because we branched Develop off of Master, and then never touched Master again.
Click the big, green, “Create Pull Request” button. You’ll be taken to a page where you can fill in some details. You can ignore the entire right sidebar. It’s super useful for teams, but pointless for this exercise. Just give your pull request a title, something like “Merging Develop to Master” and a short description, like “Chris waited way too long to write this tutorial, so there’s no way I can cover all the changes this makes to Master except by saying that it creates the entire app.”
Then click the green “Create Pull Request” button. Once again you’ll find yourself on a new page. See, the thing is: creating a pull request does not actually merge your changes. It just collects them up. You could actually continue to commit new code to the Develop branch, and the pull request would be automatically updated with new commits. Additionally, other team members have the opportunity to comment on the proposed changes. They also could check out the branch, make changes, and commit them in order to update the pull request. Since you’re the only team member in this instance, you can either ignore all of that, or spend a while talking to yourself. I won’t judge.
If you’re ready to just do this, click the big green “Merge Pull Request” button, then the confirmation button, and then let it do its thing. You’ll be notified that the pull request has succeeded, and it’ll tell you it’s safe to delete the Develop branch. You can do that if you’d like. Personally I tend to leave Develop around and continue working in it, then merge to Master when appropriate. This requires doing some periodic merging though to keep Develop aware of Master’s state, which is more than we can cover here, so you might be better off just deleting the Develop branch and then making a new one (“develop-2” perhaps, or better, a branch with a name that describes the features you’re adding, like “sort-user-lists”).
All right, we’ve merged all our changes to master. Let’s get our files onto our server. The first step in that process is, unsurprisingly, connecting to the server, so fire up SSH in your terminal, or in PuTTY, as described back in tutorials 80 and 81, and log in as your superuser account (not root). Then type the following:
And create a new folder with the following command:
sudo mkdir musiclist
You’ll need to input the sudo password that you set up in the previous tutorial. The nice thing is: once you’ve done this once, you can continue using sudo commands without having to type it every time … although there is a timeout if you wait several minutes between commands.
Anyway, let’s get our app into that directory. Type this:
sudo git clone [your repo URL] musiclist
This will clone the repo to that directory. If you don’t know your repo URL, you can find it by going to the top level GitHub page for your repo and clicking the green “clone or download” button.
That should clone pretty quickly, and afterwards you can cd to the musiclist directory and do a quick
to take a look and make sure all of your files are there. Great! We’re all set to run Yarn and get our modules installed, so just—hold up. Have you seen the flaw here? That’s right … we don’t even have Node on this system yet, much less Yarn.
In our next tutorial, we’ll rectify that situation. See you then!