Contents

0.1 for the impatients

1 Deploying from GitHub to a Server

for the impatients

Set up the new bare repo on the server:

$ ssh myserver.com
Welcome to myserver.com!
$ mkdir /var/git/myapp.git && cd /var/git/myapp.git
$ git --bare init
Initialized empty Git repository in /var/git/myapp.git
$ exit
Bye!

Add the remote repository to your existing local git repo and push:

$ cd ~/Sites/myapp
$ git remote add origin ssh://myserver.com/var/git/myapp.git
$ git push origin master

taken from https://www.sitepoint.com/deploying-from-github-to-a-server/ with edit

Deploying from GitHub to a Server

GitHub, and the Git version control system it’s based on, are fantastic tools for managing and collaborating on projects – code-based or otherwise.

In this article, we’ll look at options for making Git and GitHub projects fit better into developer workflows, allowing for a smooth and hands-off deployment process.

I’ll break these options into the different types of toolsets available – which allow for options from automatically running tests and code checks to deploying your code to a server.

Why Do This?

With these automated processes up and running, you and your team can focus purely on coding, approving and merging code, rather than spending hours on deployments and repetitive tasks every time a new build or change is ready.

Disadvantages of Automation

The main problem with automatically deploying changes is that changes are automatically deployed. You have to trust your team and the code they write. This is why automatic deployment is typically paired with automated testing, and the tools presented below reflect this.

Of course, it also means that any small issues are equally as quick to fix. Automation should be paired with communication. If pushing to a repository’s master branch can trigger live builds, it needs to be clear when this happens and who can make it happen.

The initial setup of an automation process can take some time to get right. It’s important to weigh up whether or not your team or workflow really needs it. Add up the amount of time you spend on testing and deploying new builds – and if it’s more than a few minutes each time, then it’s worth it.

Git Hooks

Git has a suite of in-built hooks that can be used for automation, and these are often our first port of call for processing tasks after particular Git actions. These are divided into server- and client-side hooks.

Server-side hooks are for events such as listening to network operations – for example, when a repository receives a push. Client-side hooks are triggered on actions that occur on a developer’s machine, such as commits and merges.

There’s a full list of hooks in Git’s documentation. I’ll look at a couple here to get you started. Hopefully you’ll start to see how they may be useful in your own projects and current (manual) workflows. The hooks are files that can contain commands in any language the host system can run, allowing for a lot of power and flexibility.

`pre-commit`

This client-side hook runs before any other hook, and before any changes are committed. It’s a perfect place to run tests or other checks on your code.

Let’s add some basic JavaScript to our small project (and yes, there is an intentional mistake here):

document.onload = function() {
    alert("Hello World")
};

We’ll use JSHint to check the JavaScript for errors. (You can find installation instructions here.)

Rename hooks/pre-commit.sample to hooks/pre-commit, and change the contents of the file to this:

#!/bin/sh
jshint index.js

Try to commit the changes:

git commit -m "adding Javascript file"

You’ll see the following error message:

index.js: line 5, col 25, Missing semicolon.

1 error

Add the missing semicolon and try again. The commit will now progress without any problems.

`post-receive`

This server-side hook triggers when a push to a remote Git repository completes. In this example, we checkout the latest version of a simple website into our webserver directory, effectively a (basic) deployment.

I have an existing website that consists of an index.html page – along with some other pages that we’ll use in later examples. You can create your own or use the repository set up here.

Remote VPS

Clone the repository, specifying the --bare flag to create a repository that only consists of version control information and not our code base:

git clone --bare https://github.com/sitepoint-editors/appname.git appname.git

Now we’ll create our hook:

cd appname.git/hooks
vi post-receive

Add these lines to the file:

#!/bin/sh
git --work-tree=/var/www/html/appname --git-dir=/var/repo/appname.git checkout -f

Note: these locations are relevant to an Ubuntu installation, so remember to change paths to suit your setup, and appname directory relevant to your app must be present, otherwise permission denied happens.

This command will checkout the current repository into the defined working directory, but without any version control data.

We need to make the hook executable:

chmod +x post-receive

For first time push to this remote bare repo we need to reset remote repo to head (otherwise first time push will fail wiht message "everything up to date")

git reset --soft HEAD^

Just in case main branch name is different (local main branch is master but remote ain branch is main), use below to change HEAD to correct branch

git symbolic-ref HEAD refs/heads/[correct-branch]

if you got error
error: remote unpack failed: unable to create temporary object directory
or ! [remote rejected] main -> main (unpacker error)

usually its because permission error, redo the chown -R $USER to project root directory and chmod +x to post-receive

Local Machine

On your local machine, clone the repository as normal, using your tool of choice, and add a new remote for the live server (remember to change the server details to your webserver and user details):

git remote add prod ssh://user@domain.com/var/repo/GitHub-Auto-Deploy.git

To deploy to our production server instead of the repository, enter:

git push prod master

If you look inside the var/www/html folder, you’ll find the index.html file automatically copied into your web folder.

If you’re using your own Git repository, you can have it located on the same server as your application, and deployments are now automated. If you’re using GitHub or another external Git service, then this hook has not completely automated your workflow, but rather has reduced it to one step. This can then be simplified further.

One option is using rsync or scp commands in the post-receive hook on GitHub. Another option – especially if your application needs a build process before going live (GitHub limits possible commands) – is to use the post-receive hook to trigger scripts on your application server that checks-out your code base from GitHub (with the -f option) and runs any other necessary commands. This is starting to get complicated, which leads nicely to our next set of tools.

Autodeployment Directly from GitHub

GitHub has its own documentation for automating deployments to integration platforms, some of which are hosting providers.

To be honest, most of the documentation I checked out was incorrect, inaccurate or unhelpful, so I did some searching to link to official documentation on some popular hosting providers, and for any others I suggest you use the post-receive or continuous integration methods:

Continuous Integration (CI) Services

There are a myriad services available that can watch your GitHub repos for changes and not only then deploy them for you, but also perform other functions such as running tests and build processes for you.

Moving to a new and more complex example, we could use CI to automate the build process of a project. Firstly, pulling the Master branch of a repository, triggering a bash script to run the build and deploy process, and then tweeting about the updates. The CI and web services could be on the same server or on different servers depending on your preference.

Let’s take a quick look at some of the most popular.

Jenkins

You’ll need to set up your own Jenkins server, which means you get complete control, but it requires maintenance. Fortunately, it supports many platforms, including Docker if you just want to experiment first.

Jenkins achieves most of its functionality with plugins, and thanks to its age, open-source nature and popularity, it has a lot of plugins. For example, there are plugins for Git, GitHub and Twitter.

Jenkins requires a lot of configuration, and sometimes piecing together the instructions you need to construct your desired workflow can require a lot of research.

Travis

Again, the instructions for integrating Travis with GitHub are out of date in GitHub’s documentation. It’s even more simple now: read the Travis docs to find out more.

Travis doesn’t require any hosting or server setup, so if you’re keen to try CI without investing too much setup time, it’s a good starting point. However, extending it beyond its (comprehensive) default integrations will involve some extra config work. For example, Tweeting requires access to webhooks.

Travis has a habit of being slow to notice updates in your repos – especially in its own configuration file. These issues can then be hard to solve, as you have no access to the Travis server itself.

Other Commercial Services

Continuous integration is increasingly popular, so there’s been a plethora of new services and applications – many released by the creators of tools you may already be using, and which will fit snugly into existing toolchains and workflows. Here are some examples:

Wrap Up

Hopefully this brief introduction has clarified a few things for you regarding how this kind of deployment works. We’ve certainly come a long way from the days of FTPing your files to your server!

If you have any questions about the processes described above, please let me know in the comments.

Git deploy to VPS