Someone recently asked me what my workflow looked like on a daily basis. Instead of responding with a long comment, I wanted to write it up.

Here is what my development workflow (AKA DevOps) looks like on a site. And this would look different based on what host I am using. For example, in my opinion there are different workflows and DevOps based on the host. Here are the various types of different workflows:

1. WP Engine
2. Pantheon
3. Azure Websites
4. VPS/Dedicated Hosting
5. Shared Hosting

Each of these require different DevOps because each has a different implementation. For example, with WP Engine you have two (2) remote branches (production & staging) to push. With Pantheon (and MultiDev enabled), you have your own branch, Dev, Test, and Live. With Azure Websites, you have unlimited deployment slots which integrate fantastically with Bitbucket and Github. With VPS or Dedicated Server hosting, you could have root access where you can create a development user and use SSH/WP-CLI and Git for development. With Shared Hosting, you usually have jailed access, which causes some consternation. However, there are some workarounds. With the later two, I typically will use DeployHQ or something similar to deploy my Git changes.

If you are a WordPress development company, I highly recommend WP Engine first. Otherwise, if you are a web development company, whether you use Drupal, WordPress, or Joomla, I recommend Pantheon as an agency. Both of these companies take great care into DevOps. Now, if you have someone who insists on the Microsoft stack, I do recommend Azure or Rackspace. However, Azure PaaS has phenomenal DevOps, second to none really.

The Setup

Since all these are different and I have been writing about how I created my site, I am going to share how I use Version Control with WP Engine. Assuming that the person has either their own WP Engine account (and I do not recommend using your own account for a variety of reasons), the fun starts! In the WordPress dashboard, go ahead and create the staging site. This will ensure that you have both a staging and production sites.

Next, in my Vagrant installation, I provision a local WP installation using VV via Git Bash (Git for Windows). I have made some changes to my VV (which I need to update my Github to demonstrate) which allows for setting defaults via one's SSH profile. Since I am a Genesis developer, my basic site has my Genesis Child Theme skeleton (called Arche), Genesis, and these plugins: Akismet (already installed for you), Gravity Forms, BackupBuddy, Soliloquy, DB Sync, Genesis Shortcodes, Jetpack, WordPress SEO (AKA Yoast SEO), and my development framework as a Must Use (wp-content/mu-plugins). I will be writing more about my development framework in the weeks to come. For anyone that does not use Vagrant there are a variety of options to use like Desktop Server.

While the local vagrant site is provisioning, I create a repository with Bitbucket.

The reason I use Bitbucket is that it allows a free private account up to 5 members on a team. If you need, create new accounts for each client and add yourself as the primary team member and administrator.

Generally, then I have my environment setup. As a way of summary, here are the steps we have already taken:

1. Create WP Engine account.
2. Create WP Engine staging site from WordPress dashboard
3. Create local development site
4. Create Bitbucket repository

Next, I complete the setup of my local site.

1. Initialize Git repository.
2. Add Bitbucket remote repository (called origin)
3. Add WP Engine staging remote repository (called staging)
4. Add WP Engine production remote repository (called production)
5. Check my Git profile to ensure that my email and key are autoloading
6. Add my .gitignore. I always include my .gitignore that versions WordPress (here's a .gitignore that does not).
7. Make my initial commit
8. Setup PHPStorm & my GruntFile/GulpFile.

(Please note that in my vagrant auto site creation, I have automated the above. The name of the site [e.g., {SiteName}] also sets the Bitbucket repository (https://bitbucket.org/{YourUserName}/{SiteName}) and automatically adds all the remotes [WP Engine Remote ([email protected]:production/{WPE-SiteSlug}.git)].)

Now, I am ready to write code.

The Workflow

Now that everything is set up, I get to work. I am going to speak very generally here because I have a post coming next week that explains this in more detail. (When I am developing alone, I tend to take some shortcuts unless I am developing on a high traffic site. So I am going to assume the high traffic site.)

At first, I will develop directly on the staging branch until I get to my first milestone or place where I allow the client to begin looking and reviewing the site. Once at that place, I begin feature development. I checkout a new branch, develop until the feature is complete, then merge that branch into my staging branch for review by the client. For example, let's assume that I have the site's home page, blog page, and basic inner pages complete. Now I need to add some sort of e-commerce, CRM integration, etc. Whatever feature I am working on, I create a new branch to create that feature.

As I develop, I commit on "minor" changes commenting on everything (though Nathan Rice and Gary Jones have often gotten on me for creating commits that are too large). So for example, in functions.php:

I commit with a message like: "Add Genesis menus theme support". And so on. I keep my messages quite short so as not to slow down. Now, I will often make several local commits before pushing to origin and/or staging remotes.

When there are more than one people committing, there are extra steps of fetching and pulling to keep in sync with everyone. So then it looks more like this:

1. Fetch
2. Pull
3. Merge locally
4. Push origin
5. Commit...commit...commit...
6. Push origin
7. Push staging

When doing feature development, it looks more like this:

1. Fetch & Pull
2. Merge locally
3. Push origin
4. Checkout new branch (e.g. feature-branch)
5. Commit...commit...commit...
6. Push origin
7. Checkout staging
8. Fetch & Pull
9. Push origin
10. Merge feature-branch into local staging branch
11. Push origin
12. Push staging

That seems like a lot of steps, but when compared to the alternative of using backups and FTP, I prefer it! You also can create .bashprofile aliases where some of these steps are combined into one step. And if you want, you can drop the origin (Bitbucket) part that I have when using WP Engine or Pantheon. I include this for my benefit and the client's benefit, which I explained in my last post, My Genesis Site: Using Version Control.

And finally, I am always asking others what they do, how they develop, and what their workflow and DevOps looks like. What does yours look like? What do you do that is different? How would you improve my workflow?

Recently, I have had multiple discussions with developers who only use FTP for development. One agency told me that they even use FTP for development with multiple developers. This completely shocked me!

I use version control on every site, theme, or plugin I develop. You may believe it is overkill but I cannot express how many times this has saved me and even my clients. 

So why do I use version control? There are six basic reasons why I use version control.

1. Mistakes. I make mistakes. Everyone makes mistakes. It is human nature. Not planning for those mistakes is planning for failure or lost information, lost time and lost money. 
2. Offsite Backup. With each site, theme, or plugin I develop, I push my versions offsite to either Github, Bitbucket, TFS, VisualStudio Online, a private Git server, etc. This alone has proven invaluable numerous times whether it was my machine that stopped working from dying of old age or hit by a car or drop kicked or some other catastrophic event, or Act of God. All I have to do is clone or checkout the code and keep on going. 



3. Multiple Development & Collaboration. Using version control is the only way to do collaborative and team development. I have no idea how this used to be done and how many people have suffered the fate of their work being completely over-written with no recourse. Version control allows for multiple people to work on the same file and not cause each other's code to be completely erased. It does not guarantee that the code won't be in conflict and cause some merging work, but I definitely prefer that over completely re-doing everything because Bob over-wrote my file. 
4. File Maintenance. Remember the days where the files were named functions1.php, functions2.php, functions-old.php, or functions-bob.php as a way of version control. This is not what I mean at all. Instead true version control allows for me to always have functions.php with a variety of comments and messages about each version. 



5. Client-Focused. Using version control considers the clients needs before your own. It helps the client be able to switch developers easily. While this may cause you some irritation, the simple thought and even courage to use version control lets your client know that you value them. Also recently, one of my very first clients lost everything because they forgot to renew their domain and host. Since I was able to retrieve the site from my version control and quickly spin up an older version, I locked a client for life and made some extra free monies. 
6. Future-Oriented. Ever wrote a file, plugin or theme thinking that you will remember what you did and then a month later come back asking yourself, "Who wrote this!? This is aweful." Hopefully the code has comments to help you navigate what is happening without thinking. But if there isn't and if the code is under version control, you could optionally read the commit/change log and get an idea of what is happening. 

If you are not convinced and want to tell me not to use Git, maybe Matthew McCullough would agree?

And for those who believe using version control is akin to reading the matrix, here is a quick video about version control for designers:

Today I want to introduce a series where I am going to walk through how I created my site. Over this series, I am going to walk through my setup, my development processes, my theme code modifications and enhancements, and my plugins I created or used to make my Genesis website.

Setup & Technologies Utilized

In the development of my site, I used the following technologies and processes:

1. Preferred IDE: PHPStorm
2. Version Control: Git (Git for Windows)
3. DevOps/Automation: Node, Bower & Grunt (though I could have easily used Gulp)
4. DevOps/Automation: SASS (CSS pre-processing)
5. DevOps/Automation: MySQL Workbench & DB Syncing
6. Local Development Environment: Varying Vagrant Vagrants
7. Hosting: WP Engine for Staging & Production via Git Deploy

Do not let this list overwhelm or intimidate you! For Node, Grunt, Bower, SASS, and MySQL Workbench, these are things all developers can learn if they want, and I am going to give you an easy way to get up and running fairly quickly.

Theme

My site is built on the Genesis Framework. Typically I start with my own vanilla child theme to create a website so to make sure I have no unnecessary overhead and bloat. This time, I started with Altitude Child Theme but did some work under the hood to extend its features. These customizations include:

• Unlimited Front Page Sections: By default, Altitude only allows for seven (7) sections. At one point, I wanted to do nine (9) or ten (10), so I extended this to be able to change my mind easily and often.
• Filterable Background Image Sections: By default, Altitude allows you to customize this via a filter (altitude_images), which is awesome! Being lazy, I wanted a single line of code to change this. So I switched the functionality to use add_theme_support.
• Icon Fonts: I love icon fonts like Font Awesome, so I added it to my child theme.
• Different Primary Menus: For user experience, I wanted the home page menu to use single page navigation via anchors, but on other pages I wanted to go to the actual page or post instead of back to the home page. So on the home page, I display one menu and on other pages I display a different menu.
• Optimized Script/Style Output: By default, most Genesis child themes output non-minified CSS delegating this functionality for plugins and cache. Since I already minimize my CSS, there is a simple code snippet to use for production sites to output the minified CSS file. The great thing about this is that it removes the information about the theme, which improves privacy.
• Custom Responsive Menu: Call me vain, but I love great mobile menus. Genesis Child Themes have great mobile menus! But I found one that I simply love, so I wanted to incorporate it into my theme. I will walk through what I did and how I added it to my child theme for anyone else who wishes to do the same.

Plugins

My site features a small list of plugins, namely:

• Akismet Anti-spam: Spam Protection (Downloaded: 0 times)
• Display Posts – Easy lists, grids, navigation, and more (Downloaded: 0 times)
• %%name%% (Downloaded: %%downloaded%% times)
• Genesis Sandbox Featured Content Widget (Downloaded: 0 times)
• Gravity Forms
• Jetpack – WP Security, Backup, Speed, & Growth (Downloaded: 0 times)
• Simple URLs – Link Cloaking, Product Displays, and Affiliate Link Management (Downloaded: 0 times)
• Soliloquy
• Soliloquy - Featured Content Addon
• Widget Logic (Downloaded: 0 times)
• WPS Core Functionality
• WP Sync DB
• Yoast SEO (Downloaded: 0 times)

Please let me know if you have noticed anything that I missed!