Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

A Simple Workflow From Development To Deployment

In this article I’ll be taking a look at how to build a simple yet robust workflow for developing sites that require PHP and MySQL. I’ll show you how to use Vagrant91 to create and run a web server on your own computer, with the version of PHP your live site runs. I also demonstrate a process for using a hosted service to deploy files in a robust way to your live server.

This article is for you if you currently have no way to test your PHP and MySQL sites locally, or use something like MAMP2 or XAMPP3. The second half of the article will help you move away from uploading files using FTP to a process that is far less likely to cause you problems.

Further Reading on SmashingMag: Link

The Aim Of A Local Development Environment Link

When designing and developing your website, you should try to match the live web server as much as possible. This should include ensuring that paths from root don’t change between local and live versions, and that PHP modules and permissions are the same in both places. This approach will reduce the possibility of something going wrong as you push the site live. It should also enable you to come back to a site to make changes and updates and know that you can then deploy those changes without breaking the running site.

A good local development environment saves you time and stress. It gives you a place to test things out. It means that you can pick up a project, make some changes, deploy them and bill your client for another job well done.

Disaster-Free Deployments Link

If you keep a list of changes made to your site and then transfer the files one by one, you leave yourself open to difficulties caused by human error and connectivity problems. Many issues we see supporting our products are down to failed FTP transfers. A key file has failed to upload, and it is deep in the core product. It’s easy to forget to transfer a file, and it’s also easy to leave old files lying around. If the software you use has removed some files to resolve a security issue, leaving them on the server could leave you at risk even if you have upgraded.

A good deployment method ensures that the files on your live server exactly match those locally. If anything fails to deploy, you should be notified so you can fix the issue before your client or their customers see it first!

Step 1: Grab Some Tools Link

We’re going to be using some free tools to create our development environment. First, download VirtualBox8, a free application which allows you to run a virtual machine on your computer. You may have already come across virtual machines if you work on a Mac and use a Windows virtual machine for testing. A virtual machine is exactly as the name suggests, a complete virtual OS running on your computer.

Install the version of VirtualBox for your operating system.

Now download and install Vagrant91. Vagrant is an application that helps you manage virtual machines.

Screenshot of Vagrant homepage.10
The Vagrant homepage. (View large version11)

It’s possible to work with virtual machines without using Vagrant. However, each time you want to set up a new VM you have to go through the process of installing web server software and configuring the server. Vagrant helps you automate that process so that within a few minutes you can have a local web server running your site.

If you are on Mac OS X or Linux, at the command line run the following command:

sudo vagrant plugin install vagrant-bindfs

For all operating systems, run the next command to install Vagrant Host Manager12 to save you editing your hosts file by hand.

sudo vagrant plugin install vagrant-hostmanager

Vagrant requires a project folder with a text file saved with the name Vagrantfile in the root. In the Vagrantfile you specify how the VM should be set up. You can write your own configuration scripts for Vagrant, but for most cases you don’t need to as someone else has already done the hard work for you. Here we’re going to use a tool called PuPHPet13.

Screenshot of PuPHPet website.14
The PuPHPet website. (View large version15)

PuPHPet Link

PuPHPet is an online configuration tool that helps you configure a Vagrant project. You work through a form on the website, selecting options for your site, and then download a package containing a Vagrantfile and other scripts to set up a virtual machine.

Step 2: Discover What Is On Your Live Server Link

To use PuPHPet to set up a development server that is as close as possible to the hosting you will use for the site, first find out what is on the live server. You want to know:

  1. Type of Linux
  2. Web server: Apache or Nginx (probably Apache if shared hosting)
  3. PHP version: this will be something like PHP 5.4 or 5.5, etc.
  4. The configured resource limits for file upload, memory and so on
  5. Installed PHP modules; for example: gd, curl
  6. MySQL version

If you don’t yet have access to the hosting then you will need to ask the host these questions. If you do have access then you can find out for yourself.

Upload a file to the server named info.php that contains the following PHP function:

<?php phpinfo(); ?>

With your web browser you can visit and see all kinds of information about PHP on the server.

1. Type Of Linux Link

You should see an indication of the base operating system in the first line of the report “System”. Knowing that you have a Debian, Ubuntu or CentOS system might be helpful for more advanced configurations.

2. Web Server Link

This is probably Apache. If you see any mention of Apache in the initial section or in the headings below, it’s Apache. The most likely alternative is Nginx. For simple sites the biggest difference between web servers is the fact that rewrite rules are different, so if you are creating friendly URLs you need to know the correct syntax to use.

3. PHP Version Link

The version of PHP will be right at the top of the document next to the PHP logo. It might be a long string — you are mostly interested in one number after the dot. So if you see “PHP Version 5.4.4-14+deb7u14,” all you need to note down is PHP 5.4.

4. PHP Modules Link

PuPHPet will install some default modules for you. If you want to be sure certain things are present, however, you can specify them. The PHP modules are listed, with details about them, after the “Core” section of the report. Common modules to look out for are:

  • curl: for making requests to other servers
  • gd and/or imagemagick: used for image manipulation
  • mysql, mysqli and pdo: methods of connecting to the database. You should probably be using mysqli or pdo at this point
5. Resource Limits And Configuration Options Link

Under the section “Core” you will find all kinds of information about PHP. Useful settings to note down are:

  • max_execution_time: how long a script may run for
  • max_file_uploads: how many files may be uploaded at once
  • max_input_vars: how many fields a form is limited to
  • post_max_size: the maximum size of a form post
  • upload_max_filesize: file upload limit

Depending on your hosting, some of these might be able to be changed. For example, you can usually increase the size of files that can be uploaded.

6. MySQL Version Link

Under the PHP module information for mysql, mysqli and pdo_mysql you should see a value for “Client Library Version”: this is your MySQL version. Again, knowing just one value after the dot is fine.

Beware Of Old PHP! Link

On doing this test, if you discover that the server is running anything older than PHP 5.4 — stop now and find out how to upgrade the hosting to a more recent PHP version. For a new site I’d suggest ensuring you are on at least PHP 5.5. Version 5.6 is even better.

PHP5.3 is not only end-of-life, it’s also really slow in comparison to newer PHP versions. It’s a good plan to make sure you are using a supported version of a core technology on your site. Through helping customers at Perch we’ve found that, in general, hosts are happy to upgrade you to a newer server if you put in a request. If they are not, I’d seriously consider moving hosts17.

Step 3: Build A Project With PuPHPet Link

Now that you have your information to hand, you can use it to build a project with PuPHPet that reasonably closely mirrors your environment. I’ll walk you through the interface. If I don’t mention a setting and you don’t have an opinion about it, then leave the default value.

Deploy Target Link

On the PuPHPet website18, choose Deploy Target → Locally in the sidebar. In the main screen select VirtualBox as the provider.

Under Distro you can select the type of Linux you are using, if it is listed. If it isn’t listed I would suggest using the default Ubuntu.

The IP address needs to be something unique on your network, not a real external IP. I tend to use IP addresses with the format for VMs.

The hostname identifies your server. Again this can be something made up.

Shared Folders is an important setting. When you use a virtual machine you are running an entirely new computer with its own file system on your computer. If you want to continue editing files in the usual place on your computer — and not have to transfer them into the VM to view them — you need to map the drive on your own machine to one on the VM. That’s what we are doing when we create a shared folder.

On my Mac, inside /Users/rachel/Sites I have a folder called vm. This is where I place a folder for each of my projects. When I set up a VM I use the path /Users/rachel/Sites/vm as the folder source, mapped to /var/www as the folder target.

Screenshot of PuPHPet configuration screen.19
Setting up shared folders on PuPHPet. (View large version20)

If this is a new site and you don’t already have files created, at this point I’d suggest creating a folder for the project you are setting up the virtual machine for, and pop an index.html into that folder with <h1>It works!</h1> in it. Just so you can see that things are working after running setup.

Finally, if you are on Mac OS X or Linux, select NFS as the shared folder type.

System Link

You can probably leave everything here as the default. It’s worth knowing that under this option you can configure cron jobs for scheduled tasks and add system packages if you have certain things you want to install.

Web Servers Link

Unless you have identified that you have Nginx, select Apache and check Install Apache. This will open up a further set of options. Here is where you configure your virtual hosts.

A virtual host means that instead of having one website per server you can have multiple websites on a server. With virtual machines you can create as many as you like, so it’s up to you whether you configure a single virtual host or more. What you should not do is configure one virtual host and then stick multiple websites into subfolders of that host. Each site needs either its own VM or a virtual host on a VM so that the path of your files from root does not change when you go live.

The basic settings for a virtual host are as follows:

Server name: or any made up domain you like.

Document root: from /var/www. If you have shared a folder in the way I suggested, /var/www is that directory on your computer — the directory with all your project folders in it — so you can specify /var/www/clientname here.

Screenshot of virtual host setup.21
Configuring a virtual host with PuPHPet. (View large version22)

If you want to add another host, scroll down to Add an Apache vhost and create your next one.

Languages Link

Select PHP and check Install PHP.

Screenshot of language setup.23
Setting up languages on PuPHPet. (View large version24)

Under PHP Version select the version you identified as being on your host.

Under PHP Modules add any specific modules (for example, “gd” and “curl”) that you identified as present on your hosting.

Databases Link

Select MySQL and if you know the version of MySQL select it here.

You can now create a database user with a password. I tend to just use the name “vagrant” for both on local development machines.

You can also create a database ready to use for your site. Remember these details as you’ll need them to install your CMS or use in your own custom code that connects to MySQL.

Mail Tools Link

If you are using a CMS then it’s a good idea to have some way of looking at the emails it sends. PuPHPet suggests you install MailCatcher25 locally for this task as it saves configuring a mail server.

That should be it for setup. Select Create Archive from the sidebar and download your file. Unzip the file and put it somewhere on your system — mine all live in my home directory in a subdirectory called vagrant.

Your First Virtual Machine Link

You are almost ready to go. Open up a terminal window and change into the folder where you unzipped your project.

cd /Users/rachel/vagrant/mynewproject

Now run the command:

vagrant up
Screenshot of terminal window.26
Running the vagrant up command. (View large version27)

The first time you do this it will take a while. Vagrant will see that you don’t already have the base operating system downloaded so it will download it. When you create a new project in the future and use the same version of Linux, Vagrant will copy the box so this will be quicker.

You will see a lot of stuff scrolling by — don’t worry about it; it will take a few minutes to get everything set up for you. If you are using NFS you will be prompted for your password during the process to allow Vagrant to edit your exports file.

Once Vagrant has finished you should be able to go to the domain you set up for your virtual host using your web browser and see your site! If you make changes to your files and reload the browser, you will see your changes.

Basic Vagrant Commands Link

Vagrant is controlled with a few simple commands from the command line. We’ve already used vagrant up which will start up a VM. If the VM is brand-new it will also provision it — setting up the packages you configured to be installed, creating your virtual hosts, and so on. If you run vagrant up on a VM that has already been provisioned, Vagrant will not reprovision it.

Understanding the commands and what they will do is important, but if you prefer to stay out of the command line, take a look at Vagrant Manager28. Vagrant Manager is an application for Mac OS X and Windows that gives you a nice way to manage your VMs and also see which are running at any one time.

Screenshot of Vagrant Manager website.29
The Vagrant Manager website. (View large version30)

If you want to reprovision a VM, first make sure it is running with vagrant up, then type:

vagrant provision

To stop a VM from running you can use:

vagrant suspend

This will pause the box and give back your host machine the memory it uses, but it won’t delete anything on the VM or shut down the operating system. If you run vagrant up again, it will come back just as it was before you paused it.

To shut down the operating system on a VM use:

vagrant halt

Running vagrant up on a halted box boots up the system again.

If you want to set your virtual machine right back to its initial state, run:

vagrant destroy

This will delete anything you installed on the server. It won’t touch the files in your mapped drive as those are hosted on the host computer, but it will delete MySQL databases, for example. If you want the data from those, export it first.

To access the command line on the VM type:

vagrant ssh

You will then be on your VM and can run any commands. A common thing you might do is import or export a database file.

Importing A Database File Link

Our process creates an empty database. If you are installing a CMS or some other software, it is likely that it will create the tables for you. If you want to import a file exported from your live server, you can do that at the command line.

Use vagrant ssh to reach the command line of your VM. Make sure your exported database SQL script is in the root of your site, within the shared folder. Then, type the following (I’m assuming a database name of dbMySite, username and password both set to “vagrant”.

mysql -u vagrant -p dbMySite < /var/www/clientname/db.sql

You will then be prompted for the password. Type your password and the database will be imported.

Deploying Live Link

After following these steps you should have a nice way to work locally on one or more projects at a time. You can set up virtual machines that are similar to live, and you are not developing in subfolders. We can continue to enhance our workflow by moving away from FTP to using a deployment service.

Get Files Into Source Control Link

If you are already using Git, then you are part of the way to simple deployments. If not, that is the first thing we need to do. Our process will be to commit files into Git on our own computer, then create an account on a hosted Git repository and push our files to the live server from there.

If you don’t already have Git running locally, download and install Git31.

At the command line, give Git your name using the following command:

git config --global "YOUR NAME"

Use the next command to give Git your email address. We are going to use a hosted repository, so use the email address here that you will use to sign up.

git config --global "YOUR EMAIL ADDRESS"

Stay on the command line and change to the directory where you keep your site files. If your files are in /Users/rachel/Sites/vm/clientname, you would type:

cd /Users/rachel/Sites/vm/clientname

The next command tells Git that we want to create a new Git repository here:

git init

We then add our files:

git add .

Then commit the files:

git commit -m "Adding initial files"

The comment in quotes after -m is a message describing the commit. Your local files are now in Git! As you work you can add and commit files.

If you would rather not work in the command line, there are plenty of applications to help you work with Git. Tower32 is a popular choice. The people who develop Tower have also produced a great book on learning version control with Git33. You can read online free or purchase an ebook version.

Screenshot of Tower website.34
The Tower website. (View large version35)

Create A Hosted Repository Link

To make deployments easy we are going to use a hosted Git repository that will securely store your files and allow you to deploy them live. The hosted service I’m suggesting here is Beanstalk36, because it does both hosted Git and deployment. There are other services that will deploy from a GitHub account or other hosted Git service; Beanstalk bundles them together which makes things straightforward.

Screenshot of Beanstalk website.37
Beanstalk’s website. (View large version38)

After setting up your Beanstalk account, create a repository there. You now need to push your files to that repository. At the command line, make sure you are inside the directory that contains your files, and type:

git remote add beanstalk git@accountname.beanstalkapp.com39:/gitreponame.git
git push beanstalk

Your files will now be transmitted to Beanstalk. You should be able to see and browse around them there.

We can now edit our files, previewing them on our own web server. We can commit them locally and push the changes to Beanstalk. Our final step is to make them live.

Deployment Link

Deployments on Beanstalk can be manual or automatic. An automatic deployment would happen when you pushed some code into your branch on GitHub. Typically, you’d do this on a staging environment where it wouldn’t matter if the code you pushed broke things.

For a live site, especially working in our simple way, you’ll want to do a manual deployment. You will log into Beanstalk and trigger the deployment yourself.

When you deploy, Beanstalk will make sure that the files on the server are identical to the files in Git. If a new file is present, it will be added, changed files will be updated, and any files deleted from Git will be removed from the server.

To get started deploying your files, go to the repository that you created on Beanstalk and select Deployments. Here you can create a new environment and server. If you are creating a deployment to the live server, name it “Live” or “Production,” keep Deployment Mode as Manual and specify the master branch.

You can then add a server type. If you are deploying to shared hosting, that type would ideally be SFTP, but could also be FTP. On the next screen you then add your server details. These are exactly what you would use to connect with an FTP client.

Screenshot of server types on Beanstalk.40
Selecting a server type on Beanstalk. (View large version41)

Beanstalk allows you to run a test to check that your server can be connected to. Once you have your server set up, and have verified the connection, you are all set to deploy your files to your live site. It’s as simple as clicking a button and waiting. Once you deploy, Beanstalk will do the following:

  • Connect to your server.
  • Ensure that the files on the server match the files in the branch you are deploying.
  • On initial deploy, all existing files on the server have to be checked. Your first deploy will be slow!
  • Subsequent deploys only change things that have changed in Git.

Deployment Tips Link

Here are a few suggestions to make deploying your sites in this way easier.

Create A Multiple-Server Config File Link

Working across a few environments means you are going to need to manage things that are specific to each environment, such as database settings or file paths. I like to create a config file that switches on host name, so the same file can be everywhere and you can’t accidentally replace your live details with the development server ones. You can see an example for Perch42, but you could do the same for any other system that has a config file as part of the code.

Use .gitignore To Keep Things Out Of Beanstalk Link

There are likely to be files and assets that you don’t want to push to Beanstalk. You can use a .gitignore file to make Git ignore them. There are some good starting point files43 for various systems on GitHub.

Exclude Files And Folders On GitHub Link

If you want files and folders to end up on Beanstalk as part of the repository but not be deployed onto your server, you can also exclude them from the deployment. Perhaps you have some source assets you want to manage in Git along with the site, but don’t want to deploy. You can configure patterns, specific files or directories when setting up or editing your deployment.

Edit Files On Beanstalk In Emergencies Link

When you are away from your desk and need to fix a problem, Beanstalk can save the day. You can edit a file directly on Beanstalk using the web interface and push it live.

This is not as good as testing locally before deploying but handy in an emergency. Unlike editing directly on the server, you have the safety net of being able to roll back to a previous version if it all goes wrong. You also have the changed file in Git so you don’t overwrite the change next time you deploy.

Use Navicat To Sync Database Changes Link

One of the biggest problems of deploying changes can arise if you need to make changes to the live database to keep it in sync with your local one. Navicat44 can help with that job. You can select a source and target, compare differences and run queries to make changes.

Your New Workflow Link

If you’ve followed this article you should now be in a position to develop one or many sites locally, using a setup similar to how the site will run on the live server.

Your files are now version-controlled and are pushed to a remote Git repository.

You can deploy in the confidence that what ends up on the live server is exactly what should be on that server — no more, no less.

When you need to make changes to a project in the future, you can make sure you have the latest files from Beanstalk, make your changes, test, commit and deploy, and not worry that you might break something. The time you have spent getting your workflow straight should pay off the first time you need to make updates to a running site that you haven’t touched for a few weeks.

This isn’t the only way to achieve a solid development environment and deployment process, but it’s a reasonably straightforward one. Once you understand this type of workflow, you can explore how to streamline it further, making time to do more interesting things than fight with servers and hosting!

(vf, ml, og)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44

↑ Back to top Tweet itShare on Facebook

Rachel Andrew is a web developer, writer and speaker and one of the people behind the content management system, Perch. She is the author of a number of books including The Profitable Side Project Handbook. She writes about business and technology on her own site at

  1. 1

    sascha fuchs

    July 9, 2015 11:49 am

    Thanks you for the good article (personally found good tips arround Vagrant here).

    Personally i have dropped Beanstalk for a while, switched to This is more flexible because I am independent from the central gitrepo. is renamed now to Deploybot and the good thing is you are now able to build your Project before you Deploy. That can help to Cleanup the Gitrepos and makes it easier.

  2. 2

    Curious: In this day and age why would any developer be setting up PHP/MySQL on their own desktop or laptop? Surely they already have their own hosting space. If not, they can get a codeanywhere or koding account for free, but they really should have real web hosting somewhere. A Web Developer without their own web host is like a race car driver that rides a bus.

    But seriously, to get client input or to collaborate you’ll have to turn your machine n a web server. Plus eventually one of those little things that works differently on your windows machine is than on a server is going to catch up with you. those take forever to track down.
    In all, it just sounds foolish to host development sites on your own PC.

    Am I missing something?

    • 3

      Luke Pettway

      July 9, 2015 2:06 pm

      Some desktop server clients let your share a link which I think has to be set up with port-forwarding on your network. For clients though, I have a setup as follows Local Dev Server -> Staging Server -> Production Server.

      When I am using Beanstalk I set up the repository to automatically deploy to the Staging server which is usually That is the site the client will be looking at/editing if they need to work in the CMS. It is an extra step to setup the environment, but only about 10 mins~ and in the end with the auto-deploy it doesn’t cost you any time after that.

    • 4

      On the contrary, tools like Vagrant and Docker made it easy for any developer to use their own machine as reliable development web-servers without the hiccups met while deploying to a different environment, or while upgrading one’s OS — unwillingly upgrading Apache from 2.2 to 2.4 while migrating from Mountain Lion to Yosemite for instance —, because you really are able to get the exact same platform on your dev (local, then), staging and production servers.

      I don’t know of any developper coding directly on a remote server. Well, apart from myself, when I had to work for three months on an iPad SSH’ed to an EC2 instance from somewhere in the Namib desert. I suppose you have to live it to realise how much the ping delays add up, to transform a simple task into deep pain.

      Nice article. I had never heard of a GUI for Vagrant. Not sure why anybody comfortable enough with the command line that he/she is able to install Vagrant would rather use it than CLI, though.

    • 5

      Dylan Valade

      July 9, 2015 2:50 pm

      Local development with Vagrant allows us to avoid polluting the hosting space with experimental code, library versions and database structure. The virtual box lets you play with new ideas on the exact same production versions of the OS, server, language, configurations and dependencies. There is no risk nor time lost deploying and backing out ideas that need to be tested but aren’t ready for peer review or require the team to merge/rebase. If a new feature does work out, we can polish and merge the local commits into the development branch and deploy remotely for client or team review.

      Regardless of stack (PHP, Python, Node, database, server), this tutorial gets you set up with a local environment mirroring production or for a private sandbox. You can also share that virtual box with other developers and you’ll all be working on the same hosting environment while avoiding time spent coordinating micro dev deployments early in a project.
      This report is an interesting global developer survey from SO users. If you want to explore new technologies without your code being pseudo private in a cloud environment then a virtual box is perfect.

    • 6

      I mostly work with JS these days, but I still set up a WAMP environment when I need to do something that uses PHP. It’s the difference between spending a couple of minutes on the front end to set up a development environment that’s identical (or close enough) to production and making every single task take twice as long because you’re transferring files back and forth or working in a remote shell, god forbid. Personally, I have always found it faster and much less frustrating to do all the work locally in WAMP, create a distro package, upload that to production once, and sync the databases.

      As for collaboration, I use Git and shared repos. That way we can collaborate without tying up files, junking up a server, or breaking a site. Ideally, developers shouldn’t be sharing development environments anyway, not unless and until there’s some sort of integration between multiple projects.

    • 7

      Aside from the points already made, I run a three tiered setup – local dev, remote staging (for new sites or modifications to existing ones) and live. Local dev lets me a) develop even if I don’t have reliable wifi/internet, b) lets me break things in a new, experimental branch without the staging server breaking. I don’t want staging to break since at any given moment a client might be looking at it, showing it to her boss, etc. I can do risky changes locally, get them ready for the client, push them to staging and then the client can look at those new modifications when they’ve already passed my testing.

    • 8

      sascha fuchs

      July 14, 2015 11:32 pm

      The most Webdevelopers use Git, and have a Laptop. Why i need a Cloud Code Editor / IDE when i have an offline Tool that i can use everywhere. When you want to Work and you have connections issues, or the service is down you have to wait – how long you don’t know.

      I hate to wait for nothing.

  3. 9

    Luke Pettway

    July 9, 2015 2:01 pm

    I love Beanstalk to death, it is a great tool. However the problem is that when you have more than 50+ sites, some of them being smaller projects, it can be ungodly expensive. Recently I have started using Jenkins. It is a Continuous Integration tool but it can do just about anything with your code. There is an FTP Deployment plugin for it that can take your code from a repository and then push the changes files to the server.

    It took a while to setup but now I can do all sorts of things like pre-build checks for code quality, and then once the code is pushed I can run tests to see if the site is “slower” and get alerts about it. The best part is that everything is housed internally now as we are also using Gitlab for our repositories.

    This setup only took about a day or two to figure out due to having very little knowledge of how to run Jenkins and because the documentation is a little hard to understand. I will probably try out capistrano/webistrano at some point but for now I am pretty happy.

  4. 10

    Let me start by saying I’ve always been a bit of a Cowboy Coder so… All of this looks like a lot of extra work for minimal gain.

    If you install XAMPP, Laragon, or NGINX locally and figure out the 1-2 lines to change in the config files you’ll have everything you need to setup a virtual server and develop on your own machine. Will this setup be identical to your online host? Of course not, but are FTP or SSH/SCP errors really a big deal for anyone?

    Instinct tells me that Vagrant VMs and online deploy services will add several more points of failure to the whole dev-deploy cycle.

    What am I missing?

    • 11

      I feel it’s always a matter of what is your tool of choice. You wouldn’t tell the guy fixing your car that his screwdriver is so much inferior to your own screwdriver, right? =D

      It’s the same with the discussion about GRUNT or GULP – or the ultimate “line in the sand” discussion of indentation (tabs vs spaces omg).

      • 12

        Great comment. I like the comparison with fixing the car. In the end it doesn’t matter what tools you use all that matters is that the car is properly fixed.

    • 13

      Luke Pettway

      July 9, 2015 4:39 pm

      The biggest gain that you get is having the ability to roll back code very quickly should something go wrong. You also don’t have to remember every file you modified, which is useful especially when you are working with Grunt/Gulp and have multiple files being updated and modified.

      I’ve been using Beanstalk for a couple of years now and have only had one outage that set me back and they took care of it very quickly. Should something come up where you need to get a file to a server, you can just fall back to the standard FTP upload method.

      The little bit of extra work up front saves far more time in the form of constantly having to stop and upload files, and working between servers, with the added benefits of roll-backs, multi-server deployments.

    • 14

      sascha fuchs

      July 14, 2015 11:38 pm

      Vagrant is too much for default WordPress Theme Development – when you Develop Apps that independed to a specific Environment is easier to have a ready to use VM. Sometime you have to maintain old applications that only run on a old PHP / Ruby or Node Version, so install the VM and begin to work.

  5. 15


    Good point about multi-server deploys… Hadn’t thought about that.

    As for code rollbacks…some of that is covered by GIT, etc, but roll-backs of database (and db servers) would definitely be useful.

    Note to self: Add Vagrant exploration to ToDo list.

  6. 16

    Vagrant 1.7 comes with new command called vagrant push. I’ve been using it for a while now and for me it replaced all deployment tools in the name of simplicity! Less tools in workflow makes things more straight forward for me at least.

  7. 17

    I’ve been using Beanstalk for years, but only recently discovered a killer workflow tip. As you suggest I always have my production environment set to deploy manually, but it turns out you can still make beanstalk deploy automatically by adding little [Deploy: Production] to your commit message. Works a treat for those annoying little typo fixes.

  8. 18

    I’m really glad to see more promotion of this dev workflow, its turning out to be the most pain-free setup imaginable for longer term maintenance, and even for updates.

    I develop with WordPress, so I’ve been using an Ansible-based setup/deploy method from the team at Worth looking into, though I found it a steep learning curve. Very active development too.

    Thanks for the tip on Vagrant Manager. Its nice to be able to see what’s up and what’s not without having to open virtualbox.

  9. 19

    I am not sure if this is covered in the article – I don’t think it is. If I currently have XAMPP setup with 30 different websites (and virtual hosts as well so pulls up the website22 folder), would this vagrant setup be of any improvement? Or should I stick to what I have? Also wouldn’t I end up with 30 different VMs if I use vagrant?


  10. 20

    Kenneth Brøgger-Luplau

    July 12, 2015 11:11 pm

    When using `vagrant up`, you should really use `sudo vagrant up`… Otherwise Vagrant will fail to access the home folder.

  11. 21

    John Donavan

    July 16, 2015 10:40 am

    There is a way too long process from development to deployment and to make the process successful need to have a proper workflow. Have noted down all the points shared by your side. Thanks for sharing.

  12. 22

    Too much command line, my head hurts. I’ve got enough code I need to remember in my head. If I ever need to use the command line its usually to do some “hacky” stuff in the bowels of my machine. Deploying a website should not be this difficult. Yes, I use the GitHub Mac app. The heck with that command line mumbo-jumbo. Now where’s the Tylenol?

  13. 23

    Granted, there are different workflows available and different ways of doing development. The title of the article is “A Simple Workflow…”. I have to admit I find this method anything but simple. Personally I hate everything that has anything to do with the command line. If I were excited working with the command line, I would have kept the old IBM PC/XT compatible machine with a 5.25 floppy from the 80s. That gave me plenty of opportunity for command line work :-)

    I use MAMP PRO and I love it. It’s perfect in every way for what I need.

  14. 24

    Johan de Jong

    July 29, 2015 12:42 pm

    For those with a lot of projects, and thus a lot of vagrant boxes, I suggest taking a look at Vagrant Manager (

    It’s available for both MacOS and Windows, and makes it super easy to prevent all that command line stuff.

    Currently I have over 50 vagrant boxes (generated through a custom script) with a single project in each. All I have to do now, is halt the one I’m not working on anymore and up the one I need to work on. Most importantly is the fact that I can quickly see which boxes are running and stop them (without remembering the ID’s).

  15. 25

    Hey Rachel! I just wanted to thank you (and those like you here at SmashingMag) for being willing to write and put knowledge back into this industry.

    This article in particular encouraged me to completely change the way I develop – putting more energy into doing things rightly in a professional, repeatable, scalable manner. Even though my projects are small, learning from enterprise-level best practices and emulating them on a small scale has been an enormous catalyst for technical growth.

    Thank you.

  16. 26

    So, the breakdown here is:
    – Set-up –
    • develop a baseline on a VDE.
    • create/push to repo
    • push repo to server environments

    – Fixes/Features –
    • main repo is forked to dev branch
    • ppl pull dev branch and rsync DB and work locally on VDE
    • dev branch is updated
    • prod DB is rsync’d to stage and dev branch is pushed there
    • test to make sure it works
    • if everything is okay, merge files and push to prod

    Someone please correct me if I’m wrong. Thanks.

  17. 27

    Thanks Rachel, this is an ace article. I’m fully psyched for using vagrant soon, in fact I’ll install it now.


↑ Back to top