- WordPress Deployment Part 5: Atomic Deployments In my last article, we looked at deploying WordPress using some different command line (CLI) tools. In this article, we’re going to look at how we can deploy WordPress using Git, both manually via the CLI and also automatically when you push code to your remote repository. Use Git & Composer.
- Most web hosts these days include SSH/shell access for your website.
Transcript
There are a number of different ways developers like to keep WordPress sites in Git. Some people commit everything while others may only track the theme (s), excluding core, plugins, uploads, etc.
In this video we're going to talk about what Git is. Git is a version control system, and that basically means that you can take all the changes that you make to your source code and group them into these snapshots, so you can always refer back to them later. You can see when a file was changed, who it was changed by, what was changed, and all this stuff Git can tell you.
So I'm here in GitHub, and I'm looking at the Trending Repositories for the PHP language. So if we scroll down just a bit, we can see that WordPress is actually a Trending Repository, which is pretty cool, even though WordPress development isn't even done on GitHub.
So if we look at one of the files here, like index.php, and we look at the history for this file. We can see that the last time someone changed index.php was Nacin in 2013. So it hasn't been changed for more than two years. If we click on this commit message, we can see the commit itself here.
The first part here is the commit message, and it just gives us the brief overview of what was changed: “Always use dirname() or, once available, ABSPATH.”
Wordpress Fitness Sites
So if we scroll down we can see that 105 files was changed, and if we scroll down here we can see all the changes made. So this is really the power of Git. All this was recorded more than two years ago, and we can still see it, all this information.
Another thing about Git is that it has this concept of branching. So if you're working on a new feature, you can sort of branch out, and then you can work on this feature in isolation without having to commit your changes to the master branch, which is probably what is in production on some server. So you don't want to mess around with that, you just want to go out of one branch and work on it, and as soon as you know it's ready and it's ready for production you merge it into the master branch, or whatever branch you use, as your main branch.
So this is a tool called GitX, and it shows you, it's sort of a GUI for Git, so you can see all commits, and branches, and all the stuff you need. So this is actually all commits made to WordPress during the last, yeah since forever. So this is all the commits to the WordPress repository. They're all recorded here. If we scroll down here, what you see out here is the master branch. If we scroll down just a bit, you can see something happens here. So around here there's a new branch going out, and that's actually the 4.4 branch, and they started working on these 4.4 features like the “About Pag”, and all this stuff. Then here it's ready so they tagged it, the 4.4 tag, that means that they can always refer back to this tag, to get this specific version of this source code. The 4.4 version of WordPress.
You can see that they still added a few commits after that because some of the bug fixes that they're making on the master branch, they still want to apply those to the older versions of WordPress for as long as they're supported. So you can see that here they branched out, and that marks the end of development on WordPress 4.4.Then over here on the master branch they continued working on what is going to be version 4.5 of WordPress.
I think that shows some of the main concepts of Git. Just so you sort of have an idea of what it is, and what it could be useful for. So I think that's all for this video. I hope it was useful to you and I hope to see you in the next videos.
Thank you.
All Lessons
WordPress and Version Control
Wordpress Fitness Themes
There are many reasons you might want to keep a WordPress site — or parts of it — under version control. The potential benefits of version control are much the same here as they are for any other kind of project. You'll be able to experiment fearlessly, knowing that you can always get back to an earlier version of your code. Branches let you develop new features while simultaneously implementing fixes in your production version. Using a hosting service like GitHub, Bitbucket or GitLab, you'll not only have code backups with a full history of development, but collaboration with other developers will also be a lot smoother.
However, WordPress was conceived at a time when the use of version control was less ubiquitous than it is now. For example, the first release of WordPress was in 2003, while the first release of Git took place in 2005. Of course, there were capable version control systems long before Git, but considering the widespread use of Git in the industry today, this may serve to put WordPress in its proper context.
In other words, WordPress probably wasn't made with a version-controlled workflow in mind and, as anyone who tries to apply one to WordPress discovers, this does cause some issues. Unlike with some more modern systems, there is no single best way to do things, no generally accepted best practices. Still, people have given this topic quite a bit of thought, and the WordPress community has come up with some solutions and workarounds! By applying these techniques, you can get many of the benefits of a version-controlled workflow in your WordPress project with a minimum of the headaches.
Coming Up
In this article series, we'll look at some scenarios where you might want to use Git with WordPress, along with ideas on how to approach them. Moving from simple to more intricate workflows, we'll start with a couple of basic examples and then go on to introduce concepts like Git submodules and the Composer package manager. We'll also take a look at a couple of WordPress plugins that can be integrated into your workflow in order to streamline some aspects of it. Hopefully, the series will serve as a good overview of the different options available. Let's dive right in!
Scenario: Developing a Standalone Theme or Plugin
First, we'll quickly touch on the scenario where you're developing a standalone plugin or theme. This differs from the other scenarios which concern themselves with developing and version-controlling a website, and is the simplest of our scenarios. In this case, it probably makes sense to keep just your burgeoning plugin or theme in version control. You'd make the directory in question a Git repository, tracking changes here as you develop your project. While you probably use a WordPress installation to test it, the project is not directly tied to any particular WordPress site, and so the other aspects of the site don't belong in your repository.
Below is a quick look at how that may work. Let's assume we're working on a plugin, but haven't created a repository for it yet. Our plugin is in the usual place in
wp-content/plugins
inside the WordPress folder, and the contents of our plugin directory look something like this:We want to add most of these files to the repository. The
assets
directory, though, contains files that are automatically generated from files in the src
directory, using a build tool like gulp. Best practice is to not include files that are automatically generated from other files in your repository, and so we create a .gitignore
file with the following contents inside the plugin directory:Then, we initialise a repository in the plugin directory and add the relevant files and directories to it:
Next, we do some work on our plugin, editing some SCSS for example, resulting in
git status
reporting the following:We then commit our hypothetical change:
Now,
git log
shows a record of our changes:Wordpress Git
As we keep working on our plugin, we can always check the development history, compare versions, and work on different features in separate branches. In addition, let's say we've created a remote repository for the plugin on a hosting service like GitHub. We can now push up our local repository, which gives us a code backup and makes collaborating with others easier (remember to substitute your own username and repository name):
To be sure, it's possible to expand on what's included in the repository. For example, we could have automated tests that essentially create a temporary WordPress installation programmatically. Maybe we have one or more Docker images with different WordPress setups used during development and testing, and the configuration of these are included in our repository. There are many options, but in this scenario it seems likely that the repository is focused on the plugin or theme.
What benefits will Git give us in a situation like this?
- For one, it lets us try new things without worrying about losing any work. If we make commits every time we complete a self-contained chunk of work, we'll be able to jump back and forth in our development history, undo changes, compare versions and find out when a particular bug was introduced.
- Using branches, we can try out new ideas without affecting the main line of development, discarding or integrating the ideas as we go along.
- If we are working on our project with others, a Git hosting service such as GitHub, Bitbucket or GitLab will be a great help in integrating the work of all developers and distributing the latest changes to everyone.
Scenario: Developing a Site by Creating a Custom Theme
A scenario that is very similar to the one above is developing a site by creating a custom theme, keeping only the theme in version control. In this case, we might have a WordPress installation running on our computer, another on the site server, and possibly some testing or staging installation. We keep only the theme directory in version control, handling the WordPress installations and their content separately. For a simple site, this might be a good solution, giving us version control without the challenges that come with trying to keep more things in Git. The drawback is that the rest of the site lives its own life outside of Git, and so we don't have all of the development and history of the project in one place.
The steps for this scenario look much the same as the steps for the scenario above. Instead of repeating those, we'll look at how the workflow plays itself out in the Tower Git client. Similarly to the earlier plugin scenario, we have a theme we're working on, but not yet a repository. The theme resides in
wp-content/themes/my-awesome-theme
inside our WordPress directory, with the following files and directories:To initialise a repository here, we just drag the folder into our repositories in Tower and choose 'Create Repository':
Again, we don't want the
assets
directory to be added to the repository, as its files are automatically generated. The same goes for the style.css
file. To accomplish this, we just right-click the files inside Tower, choose 'Ignore → Ignore This Item', and Tower will generate the .gitignore
file for us:We stage all the files and create our initial commit:
After making some changes and committing again, our development history is available right in Tower, and, as before, we can check the development history, compare versions, and work on different features in separate branches — this time, right in Tower!
Wordpress Github
The benefits are largely the same as mentioned for the previous scenario: code backups, fearless experimentation, collaboration... In addition, Git may be useful when we want to deploy the changes in our theme to the site. For example, a script on the site server could pull down the latest code from a hosting service and execute some build steps, or we could use an automation tool like Ansible to accomplish the same thing, or a dedicated third-party deployment service. In either of these cases, deployment likely starts with committing the latest updates to our Git repository.
Conclusion
That's it for the first installment in the series. We've looked at keeping a plugin or theme directory in version control using Git, and considered some benefits this brings us. In the next article, we'll go beyond the basics and expand our repository to include WordPress core files as well. We'll consider the cases where this makes sense and the ones where it doesn't, and deal with some of the challenges such a workflow brings with it.
Make sure to get notified when the next article is available — simply by signing up for our newsletter below or by following us on Twitter.
Join Over 100,000 Developers & Designers
Be the first to know about new content from the Tower blog as well as giveaways and freebies via email.