Maintainable WordPress Development 3/3: Maintenance and Feature Development

We’ve finally made it to blog post 3/3 in the “Maintainable WordPress Development” series. In this post you’ll see how you can maintain and even update your project with new features in a way that is both easy to implement and easy to use and which will also make your life a whole lot easier.

Maintenance is the final step in the development process. This starts right after the project gets deployed to the production environment and is usually done by the same team who built the project itself. During maintenance bugs that have been noticed by the client or by the users/visitors get fixed, components get updated (like plugins, WordPress etc.) and sometimes even new features that were not part of the original project scope get developed. One thing that you as a developer need to watch out for is that not all fixes, patches and features will get deployed at the same time or in the order in which they were developed. Sometimes, they might even get discarded by the client. So, how what’s the best way to handle such a scenario? Proper VCS implementation!

In the previous blog post of the “Maintainable WordPress Development” series 2/3 we talked about the most popular current Git workflows and we also talked about how workflows can affect the project development for better or for worse. Git workflows largely affect maintenance as well because some workflows allow you to develop multiple features, patches and bug fixes at the same time as keeping the code from one feature away from affecting the second feature and vice versa. If you’re using this workflow during the project development, maintenance of the project should be pretty straight forward. Here’s an example of how it should work in general…

In the picture above we have a single branch called master. Master branch is also known as a stable branch which means that the code from that branch should always be, you’ve guessed it – deployable. Now, let’s say that you need to develop a new feature called “Cool Hero Slider”. In order to keep the master deployable you’ll need to create a new branch for that exact feature. For the purpose of this blog post let’s call that branch “cool-hero-slider”. In order to create that branch you just need to type in the following command:

git checkout -b cool-hero-slider master

In order to keep things organized it really is good practice to name branches something like “cool-hero-slider” rather like “ISSUE-267” or “ISSUE-20151030”. If you really need to use the issue ID (like when using JIRA for example) you could name branches something more like “ISSUE-267-cool-hero-slider”. This can prove to be very helpful when you have 5, 10 or even more open branches because this naming convention can help you quickly find the branch you need to work on. Now, let’s say you’ve made some changes to the code and that you’ve committed those changes against the “cool-hero-slider” branch. Having that in mind, the source tree should look something like this:

Just when you were think the “cool-hero-slider” is ready for deployment you get a urgent bugfix request. Again, in order to keep the master deployable you’ll need to create a new branch and commit the bug fixing code against the new branch. So let’s create it using the following command:

git checkout -b hotfix master

Now, once you’ve written and committed that bugfix you need to deploy it to production ASAP and you need to deploy it before the cool-hero-slider feature because, hey, request for the cool-hero-slider just got updated and you need to do some more work on it afterwords. Luckily, this isn’t a problem when using the feature branching workflow because all you need to do is to switch to the master branch and merge the bugfix branch by typing in the following commands:

git checkout master

git merge hotfix

Now all changes made to the hotfix branch are merged to the master branch while the cool-hero-slider code is still safe and sound within its own branch. The source tree now looks something more like this:

Dont forget that you still need to update the cool-hero-slider because of those new requests. To do that you will need to switch back to that branch by typing in the git checkout cool-hero-slider command, make necessary changes and commit them against that same branch. Once you’re sure that the code is ready to get deployed, you’ll need to merge those changes to the master branch as well and deploy them from there. To merge them to master you will need to type in the following commands:

git checkout master

git merge cool-hero-slider

Now you’ll be prompted to enter the merge commit message. You can either enter your own or leave the default one and that’s it! You have now successfully developed one new feature and one urgent bugfix within 2 seperate branches and you’ve merged them to master branch in reverse order without any issues and here is how the source tree of the project should look like now:

Keep in mind that this use case is also the most simple use case that I could think of while writing this blog post. Things in reality can get far bigger, far crazier and far more complicated. In order to tackle those real life challenges, you can read more about environment branches which allow you to test certain features on a certain environment before they get deployed to production, pull requests that allow better code reviewing, release branches and even git modules.

One other thing that can help you during the maintenance is a great plan. Just by knowing what needs to be done and when it needs to be completed can help you organize your resources a whole lot better.

That wraps it up for the “Maintainable WordPress Development” blog post series! Through this and the last 2 blog posts in the series we’ve covered basically everything right from the very project setup up to automated development and maintenance of the project. Have any questions or comments? We would like to hear from you! Remember to check out the other posts in our Maintainable WordPress Development series to grasp full insight of the topic.

Maintainable WordPress Development 2/3 – Version contol and things to look out for

Maintainable WordPress Development 1/3 – Introduction, structure, tools and automation