As I run a couple of harp based web sites with a manual rollout process
I thought it is time to change this. The rollout process itself is pretty
straightforward, but it still requires you to log into the remote server,
update the git repo, execute
harp compile and copy over the data.
Automation always wins, even if it is simple.
There are several approaches to this problem
harpand copy over the data. The biggest pro is a decoupled process from the push. The biggest con is, that this is a batch job, so updates are not immediately visible. Also you do not get to know, if the rollout has failed. For this sort of task I do not want to setup an emailing job.
The nice part about this, is that it only takes three minutes to set up.
The first step is to create another repository on your destination host. The important
part is to initialize this repository as a
bare one, meaning it will not contain a
working copy, but allows us to push into
mkdir /my/repo.git cd /my/repo.git git init --bare
After initializing the repo the next step is to create a hook. Hooks allow you to fire custom scripts. Hooks can happen on the client side or the server side. A common client side hook might be running a linter or ensuring that you cannot push untested code. A common server side hook is an action executed after a push, which will be used as well here. You can read more about git hook here.
You can put the following hook into your freshly created bare repository at
#!/bin/sh # Make sure that we abort on error set -xe unset GIT_DIR BAREREPO="/my/mydomain.org.git" WORKREPO="/home/user/mydomain" WWWDATA="/var/www/www.mydomain.org" if [ ! -d $WORKREPO ] ; then git clone $BAREREPO $WORKREPO fi cd $WORKREPO git checkout -f master git pull origin master npm install ./node_modules/harp/bin/harp compile cp -rv www/* $WWWDATA
You can see, the script is no magic. You have to to unset the
GIT_DIR as this is configured
to the current repository. Apart from that configuring the bash to abort on errors is important
set -e. The rest is pretty straightforward. After optionally cloning and then updating the
repository, you can simply run the needed commands to create your static page content.
The most important step is, that whenever you push, you need to push into both repositories. The one for version control (and possibly shared with other developers) and the one on the web server used for rolling out.
git remote add rollout ssh://user@your-remote-server/my/repo.git
As you can see, there is no need to setup a public git server, when you can use SSH and just have a local, non-hosted repository. Now whenever you want to push, simply execute two pushes to both your remotes, one to update the repo and one to trigger the update on your webserver.
git push origin master git push rollout master
One other option, which was already mentioned above, is to constantly pull the content and using a read-only deployment key to pull the data from the official git repo. That would more likely be the way to go with bigger setups, especially with a bigger team doing rollouts.
One last option would be to create the content on your local system, which means in this case doing the static compilation locally and then just push the data to the remote system. One thing to ensure in that setup is an atomic update, so you dont get states where you are updating your live data step by step.
I switched to this for all of my static hosted sites to save some SSH hassle. As usual, ping me on twitter or drop me an email for your thoughts.