In a previous blog post I discussed how best to manage file and folder permissions when deploying with Git, but today I’ll show a specific example of what that post-receive
hook might look like for a WordPress project that uses submodules.
I have three servers that I can deploy to, but the post-receive
hook only deploys a project when it encounters the specified branch as defined per server:
- QA waits for a release branch
- Staging waits for the master branch
- Production waits for the master branch
Other than this small difference, the post-receive
hook is identical on all three servers to reduce maintenance.
Lastly, each server has two repositories per project:
- Bare repository – storage unit that uses a
post-receive
hook to deploy the project. - Working repository – web root that will serve the project to the end-user.
This method has several benefits:
- View a combined list of all version-controlled projects via the
/opt/repositories
directory. - Recover a corrupted web root by cloning a fresh copy from the origin.
- Prevent some issues that may occur during the deployment, since it will fail before post-receive hook is fired.