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:
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:
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...
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
symfony-rest-example.dev, but you can call it anything you like.
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.
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,
symfony-rest-example.dev. 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.
If you have found this video helpful, please consider sharing. I really appreciate it.
|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|
|26||Fixing A Bug In POST Guided By Behat||12:50|
|27||Wrapping Up With File DELETE||07:47|