You need to read this article on shipping software. It’s not just true for SAAS software it’s true for client services. Decreasing your code shipping time can improve your client relationships.

Let my walk you through how I deploy code and databases during site development and why I think it helps my client relationships.

One of the best purchases I make each month is my Beanstalk membership. My next best purchase is WP DB Migrate. Between the two purchases I have my code deploy system set and an easy way to push databases around during my development cycle.

Once I have a Git repository set up on a project I set up the deployment through Beanstalk. That means it takes me almost no time at all to push code and changes to a client site.

Once I have WP Migrate DB installed on my local and dev sites moving databases is down to a few clicks.

My time to deploy is under a minute for most changes with these two tools.

Deploy how often

When I’m building a client theme I typically deploy a few times in a day. Say I was just working on the menu and finished it, I deploy the code. Or if I finished the footer, I deploy the code.

Back when I was deploying with FTP transfers I’d always say that I’d get code up each day. Reality did not match intention. I’d be lucky to remember to get it deployed every two days.

FTP was just so much work. Login. Switch to the right directory (triple check so you don’t screw up like last time). Push all the files since tracking the changes is just a pain. Wait for all your themes and plugins to be on the server. Then I need to login to the WordPress admin and make any changes to the site – you know so the client can see the menus I just finished.

With Beanstalk I setup the deployment once for my wp-content directory and then just have Beanstalk automatically deploy. You can read specifics of my setup here.

Lately I’ve added WP DB Migrate. This plugin provides a WordPress admin based interface that allows me to pull the database from any site and push a database to any site. So when I’m in development and have created a few new pages for a client project I no longer have to login to the client development WordPress install and add the pages again. I just get to WP DB Migrate out of the WordPress admin and push the database.

Of course you need to stop pushing your local database once clients start making changes (since you’d write over their changes) but then you can just pull the client changes all the time. No more trying to figure out what they have configured wrong, just pull the database and you’ve got a copy of all the settings locally.

Communication

Sure the stuff above makes sure that I can get code out fast but how do clients know that?

When I set up a new Beanstalk repository I also add the client as a user with read access and send them instructions on how to get emails about deployment. Yes I let my clients see all the commits.

Almost every client I’ve set up on this raves about how they get feedback. They don’t have to email me and see what’s up they can tell that code was just changed and they can know what areas of the site to look at.

One of the early pitfalls with this was clients checking things right away and finding mistakes. Now I make sure to tell clients that unless I’ve emailed them and told them the site is done they don’t need to submit bug reports. I have a checklist I go over before I email them to check the site for bugs that catches any issues.

Letting a client see deployment enhanced the services I provided by enhancing my communication. Automating the whole deployment process made it so that there is no burden to that communication on my end. I just code and commit and deploy as usual and the client gets lots of feedback.

Reducing my time to deployment made my work much easier and makes providing feedback to clients on site changes as painless as possible.