In the beginning…

In the beginning there was…

Just the web and deployments were hard. I remember initially hand crafting code live on web servers. Then came the advent of FTP and life was good because we could easily work off line locally and then upload the changes to the live system. These were those ancient times before CSS and even before JavaScript. It was all HTML and image assets and it was good.

Until we learned the horror of FTP’s weaknesses. Worst among them the plain text password authentication. Many sites fell to ashes as a result of nefarious dark web types. The odd thing about FTP is that as far as protocols go it was never really the most friendly. I am still amazed that the legions of technically challenge who know “How to” FTP. It persists today when there are so many more options.

SFTP which is a secure file transfer protocol based upon the SSH may not have been the first to replace FTP but it is pretty much the defacto standard among engineers today. Many of the FTP client applications have been rewritten to support SFTP rendering the argument by some relics that they NEED FTP completely mute.

So at this point we have achieved some manual methods of deploying code changes utilizing some pretty basic technologies. While manual SFTP may work well for a dev shop of one maintaining small client sites and web apps it’s the most robust. Fortunately there are services like https://deploybot.com that off a n automated SFTP based solution.

However before we jump to that there are a few other possibilities. Depending upon your server configuration you could setup a cronjob to update the site’s code from a VCS like git on a routine schedule. For instance if your site’s code lived on GitHub then your cron script could check and pull master as things change. There is a hidden gotcha in that this would load your web root with the entirety of your VSC history. In this case meaning that you’d end up with a .git directory in the root.

One way to mitigate this is to structure your repo such that the root of your site resides in an internal directory thus keep the .git management directory out of the web root. However this technique will not work for Subversion which places a .svn directory in every part of the hierarchy. The better option is to instruct Apache to to disallow access to those pesky .FOLDERS.

For Git:

<directorymatch "^="" .*="" \.git="" “="">
	Order deny,allow
	Deny from all

For Subversion:

<directorymatch "^="" .*="" \.svn="" "="">
	Order deny,allow
	Deny from all

Some security issues you should keep in mind are setup Passwordless SSH authentication and ensure that the user id that the script executes as; has limited access to the origin of truth in terms of git we are talking Master. In addition if you are hosted on GitHub I highly recommend that you make your master branch protected and exclude this maintenance user from that group.

So this scripted git pull architecture is probably the most rudimentary automated solution you can roll out. It builds upon most of the skills that you probably already have learned from working with a VCS like git. It is not the most scalable solution but this is the first in what I hope will be a series of articles one the subject of code deployment and it does assume that you have command line access to your server(s) and you re comfortable with complete some basic DevOps tasks like setting up key based authentication, Apache and cronjobs.

In subsequent articles I plan to cover tools like deploybot mentioned earlier as well as Jenkins, rsync and Ansible.

ABOUT THE AUTHOR: Mikel King has been a leader in the Information Technology Services field for over 20 years. He is currently the CEO of Olivent Technologies, a professional creative services partnership in NY. Additionally he is currently serving as the Secretary of the BSD Certification group as well as a Senior Editor for the BSD News Network.