2 months ago, I travelled to Vienna, Austria, to attend WordCamp Europe – my favourite conference in the world! It’s such a huge event and a great opportunity to catch up with old friends as well as making new ones. At WordCamp Europe, Matt Geri did a talk on “The Ultimate WordPress Development Environment”, including using WP Pusher for deployment.
Last week I wrote a guest post over on the WP Tavern about how fundamental Git is for WordPress teams. In the post, I mention 3 signs that will make it obvious to me that your WordPress development team is not in fact working as a team – but rather as small 1-man teams. The 3 signs are:
- Lack of version control
- Lack of a code collaboration platform
- Lack of a deployment strategy
Git is a fundamental enabler of team work, so without it, it’s hard to get to step 2 and 3 in that list. If you want to read the article, check it out over on WP Tavern.
I think it is fair to say that pull requests were made popular by GitHub and their brilliant implementation of the concept. Used in a strategic way, pull requests are a very powerful collaboration tool to have in your toolbelt – especially if you work in a team.
According to OSS Watch, a pull request “is a method of submitting contributions to an open development project“. But a pull request can be more than that. If you really adapt pull requests into your workflow, they provide a great space for teams to communicate, collaborate, educate and onboard new team members. This is now the norm in most open source projects, but many development teams – especially in the WordPress sphere – are not even using Git yet. If your team have not yet adapted Git (or another version control system) into their workflow, they are simply lacking the most basics of collaboration tools. The abillity to discuss and review code changes in a pull request is just one of many reasons to use Git, but it is definitely one that is big enough on its own.
There’s a question I get quite often about WP Pusher and that is: “do you handle updates to the database as well?”. The answer to that question is “no”. WP Pusher is meant as a tool to deploy code changes to plugins and themes that are under version control with Git. I always tell people that they should take a look at the Migrate DB Pro plugin instead, since it does exactly that. Recently, I started talking to Brad, the creator of Migrate DB Pro and guess what he told me: Just as people ask me if WP Pusher can deploy database changes, people ask him if Migrate DB Pro can deploy source code changes. See where I’m going with this?
NB. I wrote a follow-up piece about this topic on the WP Tavern.
Yesterday, I was watching the WP Sessions stream, where Josh Pollock talked about developing WordPress plugins using Composer. Josh did a great job introducing Composer basics, however, I still feel a need to comment on one specific point that was missing in the presentation: Loading 3rd party dependencies with Composer doesn’t change the fact that WordPress isn’t designed to handle 3rd party dependencies in plugins.
When you use Git in your WordPress deployment flow, there is a special configuration file you should be aware of.
.gitattributes can drastically clean up your plugins and themes for end users. Follow along and I will show you how simple it is to use.
This is the story about how I wasted 3 days, but also, which is more important, how I set up continuous integration for WP Pusher with CircleCi. With a continuous integration service, you can have your tests run on every commit and ensure that nothing is broken. That is, if you have some tests to run of course.
Composer seems to be something everyone is talking about in the WordPress community these days. It is a great tool for developer productivity and code reuse. However, if you are trying to use Composer to distribute your WordPress product to end users, you might be doing it wrong ™.
During the beta testing of WP Pusher, I have seen numerous examples as to how WordPress developers use Git to manage their projects. WP Pusher is opinionated in terms of how your Git setup needs to look, in order to use the service. In this post, I will try to explain why.
These days, I’m working on the plugin that makes WP Pusher update themes and plugins directly from GitHub. Having been away from serious WordPress development for quite a while, I thought it would be interesting to highlight a few of the approaches I have been using during the development of the plugin.