Hello again,

This is the first article on a series about how do I deal with how this website is managed. I will skip the typical “how to setup wordpress” or “how to setup apache/nginx”, there are a lot of articles out there about it , and very good actually.

Today, I’ll show you how I made changes to this website, update its code and release the changes into the wild after they have been tested.

According to my colleague Abel Cabanillas my procedure is overkill for a blog, but I prefer to do it my way just in case something goes wrong.

If you don’t know what version control is, I recommend you read this introductory article.

Basically, I use GIT for version control of almost anything this days. I started using subversion but I did like how GIT allows me to do local commits and push them to the central repository afterwards. This is useful to keep a one-change-per-commit philosophy even when you don’t have an internet connection. With SVN if you did not have access to your repository, you were not able to keep track of changes. Another advantage of GIT is the fact that it actually make branches of your code, and it’s not an abstraction.

I used to have my own git server, but since I started working with people not as terminal-fanatics as me, I started to work with hosted repositories, I personally like bitbucket from Atlassian, it’s free for private use up to 5 people team. I also have a github account where someday I’ll complete my distribution of SAP helper scripts. And some stuff I’m developing for system administration in general… I think that github is the place for opensource projects, but for work or private stuff Atlassian’s bit bucket seems to be more optimized.

Now that you are aware of version control and know two cloud providers of hosting for your repositories, I really encourage you to start using it. I do use version control as a sysadmin even for my shell scripts and puppet recipes.

Let’s get our hands dirty now. When I started planning this site I created a new folder in my laptop and made it a GIT repository by running the following command on the terminal:

git init .

Now I put there all the stuff (meaning, wordpress code) and perform the first commit:

git add .

git commit

And then I create the .gitignore file and ensure that it does not take in account the wp-config.php file (also, I ensure that the typical OS files to be ignored are in that file)

Once I have the site setup and working, and all the commits are done, I create a release branch, that will be the branch I use to send all changes to production after testing.

git branch release

git checkout release

In there, I do modify the wp-config.php with the DB and host settings for production, and ensure it’s commited.

Now for the fun… getting it to the server! I use a a local hosting provider for the php server (provided by nhost.es, it’s cheap, reliable and their web server installation is of the most secure I know) , they are kind of old school and only allow me to push files there via FTP. Don’t look at me this way, most of you web developers still use FTP as well to push changes to your  websites.

The problem is that uploading the entire WordPress stack to the FTP can be boring, and timestamp changes are not reliable. That’s when gitftp gets in.

Once you complete the installation on your operating system, then you have to setup git-ftp as stated in the man page: in my case i did create a .git-ftp-ignore where I placed the files i did not want to push to the server, and then I did setup scopes (production and test) as shown in the man page and when it was done, pushing the changes to production got as easy as running:

git ftp push -s production

The first time it took a lot of time as it had to upload all the wordpress stack, but afterwards it just uploaded the changes and saved me a lot of time.

Good thing is that GIT FTP allows you to use FTP, FTPS, SFTP and FTP over explicit SSL, so if you want to secure your transmissions a little bit more, you can do it.

Happy coding! Let me know if you use another methods to push changes to your FTP servers or if you automate the process for release with a different approach.

Note for MacOsX users

I had some issues the first time i run git ftp push on my MacBook Pro, it turned out that the git-ftp release had some issues with buffering, it buffers content before pushing it through FTP , and when it ran the FTP command it spit an ugly “Too much parameters” error. What I did to fix it was modify the file “/usr/local/bin/git-ftp” (guess what, git ftp extension is a bash script, a very clever one!) and set the lines:

set_arg_max() {

localARG_MAX_SYSTEM=$(getconf ARG_MAX)

if [!-z"$ARG_MAX_SYSTEM"];then

# commented this line for buffer errors

#ARG_MAX=$ARG_MAX_SYSTEM

ARG_MAX=4096

fi

write_log "ARG_MAX is $ARG_MAX"

}

is_arg_max_reached() {

localARGS_TO_ADD=$1

#fix value to 50 to avoid parameter list too long

local BUFFER=50

ARGS_STRING="${CURL_UPLOADS[@]}"

CURRENT_LENGTH=$(expr ${#ARGS_STRING} + ${#ARGS_TO_ADD} + $BUFFER)

if [$CURRENT_LENGTH-lt$ARG_MAX];then

return 1

fi

return 0

}

I’ve to say that checking the source code in the web site it seems that currently the git-ftp code would not have the issue with the “Too much arguments”, in any case I think it’s good to keep this indications for reference.