Setting Up Our Development Environment

This video is available to view for members only.

Click here to Join!

Already a member?


In this video we are going to get started setting up an Ubuntu development environment. You don't have to have any experience with Ubuntu or Ansible to complete this video, but if you have already followed along with the Ansible tutorial series, then you are likely already one step ahead.

Firstly, we are going to download and install Ubuntu Server. We will install this inside a VirtualBox environment. This will then give us a real, working Ubuntu server instance just like we would get if we signed up to Digital Ocean and created our first Droplet, or a new Ubuntu node on Linode, etc.

This is largely next > next > next.

The only interesting parts are:

  • setting your memory limit - I use 2gb / 2048
  • setting your hard disk size - I use 20gb
  • configuring a username and password (don't forget this!)
  • installing OpenSSH - it's an option during install

We will use OpenSSH to allow Ansible to connect and do all the rest of the work.

At this point, this can feel particularly scary if you have no experince with Linux. Why not just opt for a nice Vagrant instance instead?

Well, I've covered Vagrant before, but the truth is, I'm not the world's biggest fan of Vagrant. It is cool, and it does work - but it's not perfect and it never really feels like a 'real' server to me. I mean, we don't run nginx as vagrant on a real server, so why do we do so in development?

In my opinion, and perhaps it's because I am stuck in my ways, I believe we should keep our development environment as close to production as possible. There are so many advantages to this:

  • improving your confidence with your infrastructre / linux skills
  • not having a series of workarounds purely for development
  • not involving yet another third party dependency in our stack

And yet, there are some downsides. Sharing your development environment is trickier - but Ansible largely solves that problem. Also, shared folders are a bit of a nightmare. Still, we don't have shared folders in production...

Attack of the Clones

Once we have a fresh Ubuntu server install completed, we can power this down. At this point, update this particular virtual machine to use 'bridged' networking, so the virtual machine will pick up a real IP address from your router, rather than a local only IP that others cannot access.

We change this on the 'master' image so that any future clones of this image will also inherit this network setup.

And at this point we can go ahead and clone our first copy of that Ubuntu server. Don't worry about any of the settings, machine name, users, etc. This will all be handled by Ansible.

In this case, our clone will be called, but you can call it anything you like.

Ansible To The Rescue

If you haven't already viewed the Ansible tutorial then now may be a good time to do so. You don't need to know everything, but a basic understanding of what's happening will make you more comfortable.

Essentially, Ansible is a tool that follows a set of installation scripts inside YAML files to reliably reproduce exactly what software and configuration - from Users through to specific config files of almost any service you can image - on our servers, without any involvement from us.

What's super nice about this is that we can create our Ansible scripts once and then use them to deploy many times. This means we can build a local development server, and with almost no changes - bar, perhaps removing app_dev.php config from nginx for example - we can use the same scripts to deploy our production servers also.


The repository we will be using for this is located here. You can install Ansible anywhere. I have recently switched to running it locally from my laptop as I always have my laptop with me. A centralised deploy server is another good option.

Not Perfect... Yet

The Ansible scripts are still a work in progress. A future video series will cover these in further depth.

However, for now, they will give you a working website ready for you to upload your Symfony project to. This will be available on whatever name you gave your Ansible host - in our case, Be sure to add this to your local hosts file.

In the next video we will cover the setup of our local machine to connect to this server, along with uploading our fresh Symfony install and beginning with our Behat and PHPSpec setup.

Code For This Course

Get the code for this course.

Share This Episode

If you have found this video helpful, please consider sharing. I really appreciate it.

Episodes in this series

# Title Duration
1 Project Introduction 17:13
2 Setting Up Our Development Environment 05:08
3 Installing Symfony 3, Behat, and more 13:53
4 User Feature - Part 1 17:47
5 User Feature - Part 2 07:51
6 Talking English To Your Computer 11:05
7 Teaching Your Database To Forget 07:42
8 Creating User Data From Behat Background - Part 1 14:44
9 Creating User Data From Behat Background - Part 2 11:33
10 Creating A Custom RestApiContext 17:44
11 Our First Passing Behat User Scenario 12:01
12 Our Next Passing Step 13:10
13 Securing Our User Endpoint - Part 1 17:17
14 Securing Our User Endpoint - Part 2 24:27
15 Securing Our User Endpoint - Part 3 24:47
16 Log In To A Symfony API With JWTs (LexikJWTAuthenticationBundle) 11:02
17 Implementing PATCH for Users 18:17
18 Improving our API User Experience 13:59
19 GET a Collection of Accounts 12:15
20 POSTing in New Accounts 14:34
21 PUT and PATCH for Accounts 12:14
22 How To DELETE Existing Accounts 05:11
23 File Feature Overview 11:40
24 File - Using Existing Resources as Boilerplate 15:17
25 File POST 14:53
26 Fixing A Bug In POST Guided By Behat 12:50
27 Wrapping Up With File DELETE 07:47