Wordpress + GIT + Docker SDLC Process for Professionals

WordPress is messy but when you consider the market share and community, it rather cannot be ignored. WordPress is special because of its community. I have seen people working on WordPress with their unique techniques. However, working on WordPress with a larger team is a nightmare and furthermore, changes made by client in production on files makes the entire SDLC process equivalent to hell. So I have decided upon to improve the SDLC process such that it is efficient to work with client as well as with multiple developers. The design is based on 6 basic point beginning from the point of development to production roll. Here are points:

• Environment
• Database
• Plugins
• Themes
• Assets
• WP Core and Config

Environment

When it comes to LAMP Stack, there is a lot of variation in Linux, Mac and Windows. Furthermore, the requirement of basic PHP and Apache modules vary resulting in a tedious initial setup process. Therefore, it is hard to rely on native service on OS and its easier rely on docker to resolve common LAMP stack version issues. Below is a sample docker-compose script file that allows you to setup the environment without any hassle.

Database

The database is another constrain that limits the scope of extensiblity in unified approach. Every time a WordPress project comes in, it difficult to figure out the additional table included by developer or by plugins. The only constants to reply for mapping extended functionality is to peek into posts, postmeta, users and usermeta. To simplify fetching of database and deploying into 3 variants of SDLC i.e. development, staging and production, we have to maintain DB with 2 SQL files. The first file is exact copy of production and should be kept in sync in regards to plugins, tables, posts and options. The user and usermeta should be ignore to keep privacy in clients users. The second file should be a localize file that basically changes the domain URL related entries and updates environment settings. below is example SQL file to localize a WordPress database.

Plugins

Plugins is the key fundamental that makes the bandwagon of WordPress keep going. Certain plugins such SEO, Caching, member management provides an incredible experience for clients and developers. However, such favors has certain drawbacks. Most companies just keep entire copy of WordPress onto git repository resulting in slower development process. I personally consider this as a bad practice and limits the website in factors like wordpress update, plugin update. The only deliverable item for any company is the theme folder and rest is client responsibility when it comes to WordPress. 

Many times developers modify plugins as per their liking to meet client needs. Furthermore, custom plugins are required to be made a part of deal with clients. Therefore, we end up in 4 scenarios in a large scale WordPress application:

• Unmodified Marketplace Plugins
• Purchased Plugins
• Modified Marketplace Plugins
• Custom Plugins

To manage these 4 scenarios in GIT, it is recommended to use remote location like S3 or FTP from where all plugins can be downloaded . The above mention docker file maps the location of plugins in dockers image so its user accessible. Mostly Plugins folder contains lot of unmodified marketplace plugins which can be ignore in .gitignore file like this:

plugins/*

above change excludes all the plugins in plugins folder. Later, the plugins can be fetched using WP-CLI which automates the process of replicating the production plugins. 

To handle situations where marketplace plugin needs to be customized or custom plugin should be to created, you can simple include back the desired plugin into the repository and versioning of that plugin would be controlled using our own GIT.

!plugins/custom-plugin

In this approach all three scenarios get satisfied and the bulk of git repository is also reduced.

Assets

Assets are mapped in docker file

./uploads:/var/www/html/wp-content/uploads

Assets of uploads should be entirely ignored in GIT and regular sync of assets (just like DB) should be made. Those files are major bulk of WordPress that make the maintenance job difficult if included in GIT repository. Most cases these WordPress sites are hosted on a cPanel environment with FTP access. I would recommend to customize a cron job in WordPress docker image that creates an index map in db and regularly fetches the content via FTP to keep in sync.

WP Core and Config

WP Core is mostly unmodified. For you consideration, everything besides wp-content folder is like a holy grail and should remain untouched. Always start with a fresh WP core whenever you migrate from old WordPress as older version would be contaminated with development malpractices or spyware stuff. Keep the website in check by auditing the plugins included in previous hosting site.

Use WP-CLI in deployment process to get a clean start during deployment.

The config file should be updated to streamline the SDLC process into development, staging and production sites. Below is a sample to get you started with segregation.

This is the best possible approach to maintain a WordPress site in a better SDLC process. I have experimented within the place I work and turned out to be effective in dividing the work force. The process is designed to enable a WordPress developer to work in a precised manner on theme and plugins changes and welcome other front end developer (who have no knowledge and experience in WordPress) to work inside templates directory to drive the UI Design suggested by client. Please suggest me if you have a better implementation of WordPress with GIT.