This entry-level guide will help you introduce Git and continuous deployments to your WordPress themes development. If you are already familiar with Git, skip the first part and move on to the continuous deployment section.
Objectives of this Guide
With this guide you’ll be able to:
- Set up your WordPress themes development workflow with Git and best practices in place
- Design your first delivery pipeline for continuous deployments of your WordPress themes
- Employ industry standards and best practices for your new development strategy
Why should you care about Git?
If you haven’t used Git yet, you may wonder why should you go for it. Here is a bunch of reasons.
Advantages of the Git distributed Version Control System
- Keeps track of who changed what and when
- Prevents loosing files and overwriting changes
- Enables quick and easy rollbacks of changes when necessary
- Streamlines parallel development of new features
- Facilitates collaboration with other developers
Great, huh? However, the coolest comes with Continuous Deployments with Buddy. Here is why
Advantages of Continuous Deployments with Buddy
- Faster delivery of new features and fixes
- Automation of the delivery process – predictable results with reduced effort
- Less of everything you dislike: mistakes, pasting and copying, connecting, uploading, memorizing settings, wasting time
- More of everything you love: progress, momentum, getting things done
- Sharing project status with everyone around
- Less complicated development environment – a boost to productivity
- Higher quality of your software and your life – less bugs, less stress
Bringing Git Version Control to your WordPress theme development
If you are convinced you might give Git a try, let’s move on and create new Buddy project.
Let’s get started!
Create new project and select Buddy as your Git provider.
To complete the next steps of this guide you are going to need the URL of the newly created Git repository (to push new theme files to Buddy). Copy the URL.
Create Git Repository on your local machine
Git is a distributed version control system. It means that everyone has their own copy of the project. This copy is just another Git repository stored on your local machine, from which you can push your code to the one that’s been created with Buddy.
Now we are going to create such local Git repository on your machine.
We will be working with the theme named myAmazingTheme. Duplicate an existing WordPress theme directory and rename it to myAmazingTheme.
Now you need to initialize your Git repository. Open myAmazingTheme directory in your Git client and perform this action there. Below you will find an appropriate terminal command.
$ cd wordpress/wp-content/themes/myAmazingTheme $ git init
Next, you need to add the files you want to keep under version control to the repository. The command below will add all files from myAmazingTheme directory to version control.
$ git add *
Now it’s time to add the repository you created in Buddy as a remote repository for the local repository you’ve just initialized. You are going to need the repository URL you copied while creating new project.
$ git remote add origin the-buddy-repository-url
As you already know, Git is a distributed version control system. Most operations are performed locally. To communicate with the outside world, Git uses the so-called remotes. These are the repositories other than the one on your local drive. You can push your changes into the remote (so that the other developers can see them) or perform a pull from it (so that you can get others changes).
Push your theme files to Buddy
Once the above steps are completed, you can push your custom theme files to Buddy.
First, commit them locally.
$ git commit -m ‘hey’
Then push them to Buddy.
$ git push origin master
Getting it all together:
Enjoy your WordPress theme development with Git
Since your theme is now versioned in a Git repository, here are some Git basics for you. If you’re already familiar with Git, just skip this chapter and move to the next section.
Any time you create a new file, you need to add it to version control.
$ git add yournewfile.jpg
To save your work in your local repository at a given point, you have to commit it.
$ git commit -m ’a nice commit message’
Once you are ready to push the file to Buddy and share with your team or deliver it to your servers, push the change.
$ git push origin master
Bringing Continuous Deployments to your WordPress theme development
It’s time to learn how to use Buddy’s pipelines to speed up your WordPress themes development.
Continuous Deployment plan
First, let’s assume that you have one production server, one staging server and one development server. They don’t need to be separate psychical severs – you can just use different directories.
- Development server is the server where you deploy most often. It’s perfect for sharing work in progress with someone who doesn’t necessarily have their local instance of WordPress, for example with a web designer that designed the WordPress theme but isn’t actually developing it.
- Staging server is perfect for reviews involving customers or QA team. You deploy there as soon as things get into shape and are ready for internal or acceptance testing.
- Production server is the machine where the page for the actual users is hosted. Deployments here are the not very frequent and often require prior approvals.
The above approach (employing three servers with different roles) fits projects of any scope – large and small. However, keep in mind that if you decide to organize your work that way, you need to automate certain tasks. And here is where Buddy pipelines come in handy.
To accommodate all the above roles of WordPress instances we’ll create the following pipelines in Buddy:
- Development pipeline will update the development server automatically on every push, so it will always host the most current version. You won’t need to do anything besides pushing your code to Buddy to show someone your current work in progress.
- Staging pipeline will be triggered by Buddy recurrently once a day to update the staging server for your customers. It will keep the customers involved in the development process and allow you to follow their feedback since you’ll know which remarks concern a given version.
- Production pipeline will be triggered only when you decide so by pushing a button. It will update your production server with the version of the theme you choose.
For the purpose of this guide let’s assume that all three WordPress instances are located on the same server, but in different directories, to which different (sub)domains are pointing. In other words we’ll use Apache virtual hosts for our scenario.
Creating the pipelines
On your server create the required visual hosts for all three instances. Let’s assume that you ended up with something like this:
production/public_html/ staging/public_html/ development/public_html/
In all public_html directories you should have a copy of your WordPress installation.
Now in each folder create a directory for your custom theme to which you will deploy it. You should now have something like this:
production/public_html/wp-content/themes/myAmazingTheme staging/public_html/wp-content/themes/myAmazingTheme development/public_html/wp-content/themes/myAmazingTheme
This is all you need to do on your server. Now let’s start creating your first pipeline in Buddy.
This pipeline will update the development server on every push.
Open Buddy project you created for your theme. Since you don’t have any pipelines yet, you will see a placeholder with a button Build your first pipeline.
Name the pipeline Development, select trigger mode On every push and click the Add a new pipeline button.
Next, the list of available actions will appear. Select the upload action that corresponds with your server type (FTP/SFTP/FTPS).
Provide your login details and the path to the theme folder on the server – the remote path. In our case it’ll be:
Once ready, click Test connection & add this action on success button. Buddy will send a test file to your server to check if everything works fine.
Now, as soon as you make a push, Buddy will trigger the pipeline and deploy your theme from scratch. On every next push it’ll only deploy the files that changed.
Since we’ve just made a push and have nothing new to commit, we shall trigger the newly created pipeline manually. To do this, just hit the Run button.
Upon a successful deployment you can log in to your WordPress administration panel and set the new template as active.
Now let’s create a pipeline that will update the staging instance according to the schedule, e.g. once a day at 5 pm.
Since we’ve already created the Development pipeline, we can use the cloning feature that will save us some time.
Again, click the Add a new pipeline action on the Pipelines screen and this time select the Clone existing pipeline action in the top right corner.
Since the default values are perfectly fine, just click the Clone actions button. Buddy will create a copy of the selected pipeline.
Now we have to adjust the settings to fit the staging role of the pipeline. Click the pipeline to open it and from the action menu on the right select Change trigger mode, branch & name.
On the edit screen change the pipeline name to Staging and change the mode to Recurrently. This will expand more settings; select 1 day as the Interval and set the start date to Today at 5 pm.
Click Update pipeline to save the changes.
Since you cloned the pipeline, it has the same actions settings as the Development pipeline. This is why we have to change the remote path to folder to which the Staging pipeline will deploy.
While the Staging pipeline is open, select Edit actions, order & add more from the menu on the right.
Open the action and change the remote path to:
Finally we need to deal with the production pipeline, responsible for updating the site for end users.
Let’s repeat the steps we followed in case of the Staging pipeline:
- Clone the Development pipeline
- Rename it to Production
- Switch its trigger mode to manual
Then change its action remote path setting to:
You should have three pipelines on the Pipelines screen.
We are done – we created new Buddy project and placed the theme files being developed under Git version control. This distributed version control system will now help us keep the work ordered: it will track changes, support automation and collaboration between the developers.
Later, in Buddy, we created three pipelines that will allow continuous deployments approach, with development, staging and production server. Of course this is not the only possible way to employ pipelines – you can configure this flexible tool any way you like.
WordPress themes are just an example of Buddy’s abilities. The above best practices can also be employed while working on WordPress plugins or any other web project.