Wordpress Deployment Best Practices


I.    Introduction
II.   Challenges
III.  The Workflow
IV.  Development Enviroment
V.   Staging Enviroment
VI.  Production Enviroment
VII.  Hot Fixes
VIII. Permissions
IX.   Conclusion

Introduction
This guide is aimed to help you better understand how to better deal with deployments in your development workflow and provide some best practices for deployments. Sometimes a bad production deployment can ruin all the effort you invested in a development process.


Challenges
Wordpress, as a content management system, does not provide or have a built in workflow, or deployment process. Any deployment process needs to be maintained with policy and procedure. There are 2 ways to get content into Wordpress; manually added content to a page, or import/site replacement. Copying content manually to and from environments is extremely time consuming and error prone, this should not be done, instead a cohesive workflow should be followed by all developers and contributors to avoid loss of data or content.


The Workflow
Deployments should be treat as part of the development workflow, not as an afterthought. As you are developing a site or adding content the work flow should follow the same process each time. There are 3 enviroments: Development, Staging and Production.


  • Developers work on code changes, plugins, html, css, and templates changes generally on a development workstation.

  • Once feature are implemented and tested they are copied to the staging server. The only changes from the development server copied to the staging server is code, css, template changes. No content is copied from development to staging.
  • All content changes are made on the staging server.
  • Once approved on a scheduled release date the staging server is turned live.



Development Environment


The development environment is where programmers code and test plugins, make template modification and theme and template based css changes. The development environment is typically a local install on the developers computer. Once all the programming and css changes are complete and functional are all the changes pushed to the staging server.
Content may be pulled from the staging or production server to the development server to maintain content synchronization, but content should never be pushed to the staging or production server directly from the development environment.


Staging Environment


Once the features and changes have been implemented and tested they are copied to the staging server. The only changes pushed to the staging server are code, plugin, configuration, css and template html changes.
All content changes should be made directly on the staging server and not on the production server. Once the content changes are approved they will be pushed to the production server from the live server. All staging server pushes will be entire site pushes. Wordpress does not have the ability to push partial site changes live.


Production Server


Once all code and content changes have been approved and tested on the staging server a request is made to turn the staging server to production. This will copy all the content, files, plug-ins etc that are on the staging server to the production server. This is an automated process to reduce human error and should not include copying and pasting content.
Major feature releases should be scheduled after the content on the staging server has been approved.


Hot Fixes


There may be situations where hot fixes are required, for example if there is a feature on the staging server that is not approved but an immediate 'fix' is required to go live before the staging server is approved. These are usually minor content on CSS changes. These can be done on the staging and production server directly. The changes needs to be done on both server with the staging server changed first and then the production server, in that order.


Permissions


Each developer should be able to upload code, theme, css changes to the staging server. Content changes should never be pushed to the staging server from the development environment. Content editors and contributors should make changes directly to the staging server only. Only in the special case of a 'hot fix' should any editing be done on the production server.


Conclusion


The important aspect of a deployment workflow is that everyone knows the workflow and adheres to it. Ultimately a good workflow will result in a more productive, less costly website deployment, and be a lot less error prone.