Automatic Deployment of Buddy.Works
Tutorial on Setting Up Buddy Works
Tutorial on Setting Up Buddy Works
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
Introduction
What is GIT?
Version Control System (VCS)
How GIT Works?
What is Buddy Works?
How does Buddy work? (naming convention check)
Create a new Buddy project
Continuous deployment plan
Creating the pipelines
Development pipeline
Adding your first pipeline
Running the pipeline for the first time
Staging pipeline
Cloning an existing Pipeline
Production pipeline
Happy Ending!
Introduction
This guide will help you in understanding Buddy and how it works. Buddy works help developers and web designers use GIT repository to increase efficiency by reducing the steps during deployment process. It uses your existing GIT repository to automatically deploy your code and saves you valuable time.
Here is our All-star team Lisa, Paul and Steve, building an iconic WordPress theme. They are a small team and would like to be as efficient and cost effective as possible. How are they going to accomplish that? Welcome to Buddy Works powered by GIT!
Lisa is the Project Manager and Creative Director of the team and works out of San Francisco. Steve is a savvy code monkey and lives in New York while Paul, QA and marketing guy lives on the other side of the world in Auckland, New Zealand. They work remotely and have daily and weekly meetings to go over products as well as client demonstrations. They use scheduled meetings but they work independently through GIT to make sure they have a central workspace and everything is documented.
What is GIT?
In 2005 Linus Torvalds, the founder of Linux and other Linux Kernel developers founded a version control system to keep track of changes in their code and documents called GIT. Before we get into GIT and its dazzling features, let’s talk about Version Control Systems (VCS) and why you need it.
Version Control System (VCS)
If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.
Lisa, Paul and Steve all work in different time zones and they want to see each other’s work anytime they want and compare it with previous versions. They would like to commit changes based on recent updates by their team mates and build on top of their work. This all can be done seamlessly through VCS without losing or over-writing previous versions. They all want to have a local copy of synchronized work so that they stay on top of their game without having to meet and exchange work status. More efficiency!
Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). One of the more popular VCS tools was a system called RCS, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools.
This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to. This is called local version control and not so good for our team of all-stars!
Problem of collaboration still persists. Centralized Version Control Systems (CVCSs) were developed to fix just that. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control. Well, everyone didn’t live happily ever after even with that! If the server went down or hard-disk failed, its game over!
Everyone wore their thinking hats and got together to fix it, for once and for all. This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as GIT, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files, they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data. Now we’re talking!
Let’s go back a little before 2005. Back then everyone used a DVCS called BitKeeper, a proprietary version control system. Like all good open source proponents, Linux Kernel developers hated to pay anything for tools. BitKeeper was a commercial endeavor and chose to go down the dollar path. That’s when Linus and his warriors parted ways and made their own version control system, GIT. The goal was
Speed
Simple design
Strong support for non-linear development (thousands of parallel branches)
Fully distributed
Able to handle large projects like the Linux kernel efficiently (speed and data size)
Thus came the era of code prosperity and harmony. One can ask though what makes GIT special? Let’s find out by getting deep into how GIT works!
How GIT Works?
The major difference between GIT and any other VCS (Subversion and friends included) is the way GIT thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time.
GIT doesn’t think of or store its data this way. Instead, GIT thinks of its data more like a set of snapshots of a miniature filesystem. Every time you commit, or save the state of your project in GIT, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, GIT doesn’t store the file again, just a link to the previous identical file it has already stored. GIT thinks about its data more like a stream of snapshots.
This approach makes GIT more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. With GIT every operation becomes local, uses check-sums to ensure integrity, only adds data if changes exceed current version. Alright, our all-star team is all in on GIT.
What is Buddy Works?
Now what on earth is Buddy Works and why should they use it? Buddy does to GIT what NOS does to a Ferrari! It uses your current GIT hosting (GitHub and BitBucket) and uses your code in it to automatically deploy it for internal development, QA Team testing, client demonstrations and production servers. No more hassles. Some of the core benefits of Buddy are:
Much quicker delivery of features and fixing things
Code is delivered ultra-fast
It’s automated: predictable outcomes with minimal manual effort
Less of everything you don’t like: mistakes, pasting & coping, connecting, uploading, needing to remember, time wasted
More of everything you love: speed, momentum, getting things done, moving forward
Project status visible to everyone
You’re more agile: reduced complexity of the deployment effort
Easy to enforce quality
How does Buddy work? (naming convention check)
Don’t take our word for that! Let’s put the work done by all-stars to work!
Let’s assume that you have a production server, a staging server and a development server. It doesn’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 previews to someone who doesn’t necessarily have their local instance of WordPress. For example, a web designer that designed the WordPress theme but isn’t actually developing it.
Staging server is perfect for previews for parties like clients or QA people. You deploy there as soon as things get into shape and are ready for testing and client’s approval.
Production server is a machine from which the page is served to the actual users. Deployments are the rarest here and often require approvals.
To accommodate all these roles of WordPress instances, we’ll create these pipelines in Buddy:
Development pipeline will update the development server automatically on every push so it will always serve 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 client preview. It will keep the client involved and help you deal with their feedback as you’ll know perfectly to which version client’s remarks relate.
Production pipeline will be executed only when you decide to so by pushing a button. It will update your production server with the version of your theme you choose.
For the purpose of this guide let’s assume that all three of WordPress instances are on the same server: they are just in different directories to which different (sub) domains are pointing. In other words we’ll use Apache’s virtual hosts for our scenario.
Create a new Buddy project
You need to create a new project and select Buddy as your GIT provider. (or GitHub/BitBucket)
How to create a new project in Buddy
Further you will need the repository URL of the newly created GIT repository so you can push the new theme files to Buddy. Copy the URL.
How to create a new project in BuddyGIF
Prepare a GIT repository on your local machine
Continuous deployment plan
Creating the pipelines
Preparations
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 there should be a copy of your WordPress installation.
Now in each folder create a directory for your custom theme to which we 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
Development pipeline
This is all what you need to do on your server. Now let’s start with creating your first pipeline in Buddy.
This pipeline will update our development instance on every push.
Open the Buddy project which 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.
Next name the pipeline as Development, select trigger mode. On every push, click the Add a new pipeline button.
Adding your first pipeline
Now a 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 the following:
development/public_html/wp-content/themes/myAmazingTheme
Once ready, click the Test connection & add this action on success button. Buddy will send a test file to your server to check if everything works fine.
Adding your first FTP action
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 changed files.
Since we already 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.
Running the pipeline for the first time
Upon a successful deployment you can now log in to your WordPress admin panel and set the new template as active.
Staging pipeline
Let’s now create a pipeline that will update the staging instance in an organized matter, 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.
Cloning an existing Pipeline
Again click the Add a new pipeline action on the Pipelines view and this time use the Clone existing pipeline action in the top right corner. Since the default values are perfectly fine, just click the Clone actions button. Immediately a copy of the selected pipeline will be selected.
Now we have to adjust its settings to fit its staging role. Click the pipeline to open it and from the right action menu select Change trigger mode, branch & name. On the edit screen change its name to Staging and trigger the mode to recurrent. This will expand more settings; select 1 day in the Interval and set the start date to today at 5 pm. Click Update pipeline to save your changes.
Since you’ve cloned the pipeline it has the same actions settings as the Development pipeline. This is why we have to change the remote path to which the Staging pipeline will deploy.
While the Staging pipeline is open, click Edit actions from the right menu.
Open the action that’s there and change the remote path to:
stagning/public_html/wp-content/themes/myAmazingTheme
Production pipeline
Finally the production pipeline responsible for updating what the site users actually use.
Let’s apply the same strategy as we did for 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:
production/public_html/wp-content/themes/myAmazingTheme
Adding a production pipeline by cloning an existing oneGIF
Adding a production pipeline by cloning an existing one
Happy Ending!
Easy, sleek and simple! Now Steve churns up the code while sipping his Starbucks Coffee while it snows outside. Paul does the QA and show it to clients in seething Auckland and Lisa creates eye-catching designs from her house. All thanks to Buddy that turbo charged their productivity.
Note: Images and Gifs have been deleted. It can be found on the website. This tutorial is the write up of an older version found here
https://buddy.works/guides/how-introduce-continuous-deployment-to-wordpress