Setting up git on Pagely VPS/Enterprise for 1 click deployment
Last Updated -
Run git push and then your local code will be pushed into the Pagely WordPress Instance.
3 parts are needed:
- A working repository (@local)
- A remote, bare, repository (@Pagely)
- A working directory (your deployed site or test branch @Pagely)
We want to be able to develop your application as normal, in your local working directory, and push to a remote server (@Pagely) as we normally would (e.g. Github, BitBucket etc). The remote repository though won't be a standard development repository. It needs to be what's called a bare repository, which the git scm book describes as: a repository that doesn’t contain a working directory
In Git you should only use a "bare" repository to clone and pull from, and push to. It doesn't have a checked out tree, so it just does what the "server" notionally does in a centralized VCS – records commits, branches, etc when you push to it, and gives you the latest versions when you clone or pull from it.
So in your bare repository you won't be able to edit files and make changes. It's purely there for you to push your latest changes to and for those changes to be deployed from, to our working directory.
Setting Up the Remote Repository
On your Pagely VPS server your bare repo should be setup in: /data/git and you will need to use the full path to the site for git (ie /data/sxxx/domxxxx/domxxxx) you can get that easily by running:
$ ls -l ~/sites/
The bare repo must be placed in /data/git on your Pagely VPS:
$ cd /data/git $ mkdir my_site_repo.git $ cd my_site_repo.git $ git init --bare
Initialized empty Git repository in /data/git/my_site_repo.git/
When this is finished, if you ls the /data/git/my_site_repo.git directory, you'll notice that it contains what would normally be stored in a .git directory. This is perfectly fine as the working directory in this case is, effectively, the deployed directory.
The Post-Receive Hook
With the remote repository setup, we next add a git post-receive hook. (name post-receive, in your "hooks" directory) Sample post-receive below:
#!/bin/bash # ## store the arguments given to the script
read oldrev newrev refname
## Where to store the log information about the updates LOGFILE=./post-receive.log # The deployed directory (the running site) DEPLOYDIR=/data/sxxx/domxxx/domxx ## Record the fact that the push has been received echo -e "Received Push Request at $( date +%F )" >> $LOGFILE echo " - Old SHA: $oldrev New SHA: $newrev Branch Name: $refname" >> $LOGFILE ## Update the deployed copy echo "Starting Deploy" >> $LOGFILE echo " - Starting code update" GIT_WORK_TREE="$DEPLOYDIR" git checkout -f echo " - Finished code update"
echo "Finished Deploy" >> $LOGFILE
This script, written in bash, will be fired off after the push is received by the remote repository. It manages the entire deployment process for us, consisting of the following steps:
If you are using submodules have a look here
Let's look at it piece by piece:
read oldrev newrev refname
Here we store the three arguments passed to the post-receive script when it's called. These are:
- The previous commit SHA1 hash
- The latest commit SHA1 hash
- The refname (containing branch information)
This helps track what's being deployed and to rollback should you need to do so. This script doesn't handle a rollback however.
To reiterate: Please make sure to update DEPLOYDIR to the proper applications absolute path
Next we setup a variable to log the output of the deployment and the deployment directory.
echo -e "Received Push Request at $( date +%F )" >> $LOGFILE echo " - Old SHA: $oldrev New SHA: $newrev Branch Name: $refname" >> $LOGFILE echo "Starting Deploy" >> $LOGFILE
Here we're logging when a push request was received and the details about it. That way, should we need to debug, we have relevant information to hand and a quick message to say that we're starting the deploy process.
echo " - Starting code update" GIT_WORK_TREE="$DEPLOYDIR" git checkout -f echo " - Finished code update"
Here we tell git where the working tree is, and instruct git to checkout the latest copy of the code to that directory, removing any changes which may have manually been made.
echo "Finished Deploy" >> $LOGFILE
The last step is indicating that the deploy's now complete. You'd likely do a lot more than this in a standard project, including:
- Clearing and pre-warming cache directories
- Running database migrations
- Running unit & regression tests
- Checking permissions on key directories
Reiterating Again:In the /data/git/my_site_repo.git/hooks directory, create a new file called post-receive and add the contents of post-receive sample above. You should only need to change one variable, DEPLOYDIR.
Change it to suit your needs, and don't forget to make the file executable, otherwise it won't run. If you're not familiar with how to do that, it's as follows:
chmod +x post-receive
The Git User
Whilst on the remote server, there's one step left to go, the git user. This is the user who will manage the process, and who we'll authenticate as. Your can use your current ssh login for accessing this repo, but most users prefer a dedicated account for this. Add a SSH key to your account to setup a git user. Click here for the article regarding setting up your SSH key.
Note: If you don't have one or aren't familiar with them, this excellent, short guide from GitHub steps you through creating one.
Adding The Remote Repository
After that, we're pretty much finished. In your working directory, run the following command to add the new remote repository:
git remote add pagely_test pagely_test.pagelydev.com:/data/git/my_site_repo.git
A few notes about the command above...
1. its best to alter "my_site_repo" to something you'll remember.
2. client_USERNAME should be updated to your Atomic username with SSH/SFTP access.
3. if this ssh/sftp user uses a different public key than your default public key, we suggest creating a config file in your .ssh directory like so...
With that in place, all we need to do is then start developing our application and push as required.
Since our system manages the core WordPress files you should be sure to utilize .gitignore in your repo
/* ignore WP core and misc*/ wp-content/blogs.dir/ wp-content/upgrade/ wp-content/backup-db/ wp-content/advanced-cache.php wp-content/wp-cache-config.php sitemap.xml *.log /wp-*.php /index.php license.txt readme.html wp-admin/ wp-includes/ xmlrpc.php wp-content/cache/ wp-content/backups/
db-config.php sitemap.xml.gz .DS_Store
When ready to push to your Pagely VPS, a simple $ git push pagely_test should do it.