↓Skip to main content
Dessky.org Dessky.org
  1. All Posts/

wp-yak

Tools Open Source PHP WordPress

WP Yak

Written in familiar PHP, WP Yak (WPY) is a simple, but powerful deployment tool for WordPress Plugin & Theme Development

Tested only for GitHub (BitBucket & GitLab pending). Don't use yet.

Using remote git repos on GitHub, BitBucket or your own self-hosted instance of GitLab, you can automate your deployment workflow between development, staging and production servers.
Whether you’re building a theme, plugin, mu-plugin or combinations of those for a client website, WP Yak will automatically deploy the latest code intended for a server, based on your configuration. Here’s an example:

Example Workflow

git branch
workflow stage
server

master
Development
https://dev.yoursite.com

review
Code Review
– NA –

custom
Custom Stage
https://custom.yoursite.com

staging
Staging
https://staging.yoursite.com

production
Live/ Production
https://yoursite.com

  • While developing in a team: git push origin master will deploy code to https://dev.yoursite.com
  • Once the code is reviewed internally and is ready for client review: git push origin staging will deploy code to https://staging.yoursite.com
  • Once the clients’ reviewed everything and gives a go ahead for going live: git push origin production will deploy code on the live site, https://yoursite.com

Slim & Faster Deploys

Instead of cloning and maintaining the whole repository on servers, WP Yak tries to only deploy the code without the scm data (or the .git directory, etc). Using git archive, WP Yak is able to only copy the files at a particular branch or tag, without the commit history:
git archive --remote=git@github.com:your-organisation-or-username/your-plugin.git
GitHub doesn’t allow git archive, but fortunately, GitHub supports svn clients. So, we use the svn equivalent of git archive, svn export. See: http://stackoverflow.com/a/18324428/1589999

Regular Deploys

Of course, if you wish to maintain the whole repository on your servers, you can disable the slim deploy. To do that, set the SLIM constant to false in wp-yak-config/constants.php.
This way, WP Yak will use git pull and maintain a local copy with commit history inside the wp-yak/wpd-repos/ directory and copy over the latest code to the deploy path. This is done, instead of maintaining the repo in the actual deploy path (say wp-content/themes/your-theme) to prevent over-writing by a manual upload. Without this, if someone uploads the theme/ plugin manually, the scm information will be overwritten and the deploy would break. With this mechanism, a manual upload will be overwritten in the next push!

Pre-Requisites

Make sure that the following are installed:

  • git
  • svn for Slim Deploys using GitHub

Usage

1. Getting Started

  1. Install WP Yak
  2. Setup schema for GitLab
  3. Configure repos
  4. Setup constants

1.1. Install WP Yak

Right now there’re no automattic installation methods, you’d have to clone this repo or archive its master branch using git or svn or upload the files manually.
If you’re using EasyEngine, follow these steps, after logging in via ssh, clone this repository to your webroot

git clone git@github.com:Yapapaya/wp-yak.git /var/www/yoursite.com/htdocs/

(Optional)Move wdp-config outside the web root for security, especially if you’re using tokens

mv /var/www/yoursite.com/htdocs/wp-yak/wp-yak-config /var/www/yoursite.com/wp-yak-config

1.2. (Optional) Set up schema for GitLab

If your remote repository is on GitHub or BitBucket, you can skip step 1.2 and start with 1.3.
If your remote repository is on a self-hosted instance of GitLab CE, you need to set up schema for it.

vim /var/www/yoursite.com/htdocs/wp-yak-config/webhook-schema.php

or

vim /var/www/yoursite.com/wp-yak-config/webhook-schema.php

The schema for GitLab looks like this

// Payload Schema for GitLab Instance
// your Gitlab instance's domain
'git.yoursite.com' => array(
	// your GitLab instance's IP range in CIDR format
	// use http://www.ipaddressguide.com/cidr to get it
	"ip_whitelist" => '127.0.0.0/32',
	"ip_param" => 'HTTP_CF_CONNECTING_IP',
	"token" => array(
		"header" => 'HTTP_X_Gitlab_Token',
		"hashed" => false,
	),
	"ref" => array(
		"param" => array( 'ref' ),
		"pattern" => '/^refs/head//',
	),
	"branch_name" => array(
		"param" => array( 'ref' ),
		"pattern" => '/^refs/head/(.*)$/',
	),
	"git_archive" => true,
),

The key for each schema is the domain name of the remote. The keys inside the schema:

  • ip_whitelist A whitelisted range of IP’s
  • ip_param The header that contains the IP of the remote. Leave it empty if your server directly talks to remote without a proxy in between. In the example above, the HTTP_CF_CONNECTING_IP is where CloudFlare stores the webhook’s original IP address.
  • token GitHub and GitLab (but not Bitbucket) allow you to set an additional security token that is sent as a header.
  • header The header that contains the security token
  • hashed GitHub hashes the security key, GitLab doesn’t. Set it to false, if it isn’t hashed or true, if it is.
  • ref Schema for the…


↑