Push-to-Deploy is the feature of WP Pusher that will keep your WordPress websites up-to-date every time you push some fresh code to your Git repositories. In this post, we are going to take a look at what Push-to-Deploy is, how best to use it for an effective workflow.
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.
As part of the Git for WordPress video course, Danny van Kooten shows how he uses Git to release a new version of his plugin MailChimp for WordPress.
Danny van Kooten is the founder of Ibericode and the creator of MailChimp for WordPress, one of the most popular WordPress plugins on WordPress.org. I have known Danny for a while and I know he has a pretty solid workflow, so I reached out and asked if he would like to share it, which he agreed to. Thank you, Danny!
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?
Dear WP Pusher users, I know this sucks.
Since day 1 of WP Pusher, I have used a service called WP Updates to handle automatic updates. It’s a service by Dev7Studios – or at least it was. Last month, the worst thing happened. WP Updates was down and according to Dev7Studios it wasn’t their responsibility anymore since they sold the site to someone else – someone they weren’t allowed to name. After a few days someone managed to get the site online again, but I haven’t been able to access it since. Apparently, there’s no way to resolve this, since Dev7Studios won’t disclose who the new owners are.
Months back, I worked on something called WP Shipper, which does many of the same things WP Updates does – including automatic updates of WordPress plugins. I decided to launch a light version of WP Shipper, now that I desperately need it for WP Pusher.
Today, version 2.0.0 was released. The main reason for the bump in versions from 1.1.8 to 2.0.0 was due to a few breaking changes that I felt was necessary to introduce. Please take a moment to read this post to stay up-to-date on what is new.
It’s #WCEU week and I’m headed to Seville to hang out with the WordPress community. What a great occasion to have a little contest, right?
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.