Welcome back to Introduction to Continuous Integration. I'm Ben Lambert and I'll be your instructor for this lecture.

I wanna take a small detour to talk about why having a development environment that mirrors production helps to reduce bugs.
By the end of this lecture, you should have a good starting place for setting up a development environment and you'll be able to identify why it helps to reduce bugs.

So, because there are so many tools, languages, frameworks and platforms, there are a lot of different ways to set up a development environment and there's no singular right way to go about this. Now the goal should be to have a local development environment that mirrors production as best we can.

This is important because these days you can develop on just about any operating system. And if you have three developers and they're all using different operating systems with different configurations, you can end up with some code that runs in one environment and not the others. One way to solve this problem is to use something like Vagrant and VirtualBox. Vagrant is a virtual machine management tool that allows you to provision and manage your virtual machines. And VirtualBox is a virtualization tool which means it allows you to create and run VMs.

Now, I wanna mention that because this isn't a step by step guide, it may be difficult for you to follow along. If you want to check out these tools and I really recommend you do, I suggest you watch through this lecture first and then go back and install Vagrant and VirtualBox on your operating system so you can test things out.

Okay. Let's take a look at how to use Vagrant. Our goal for this, is to set up a Ubuntu Linux VM and run a Python application. First, we're going to change directories into our project directory. And then we're gonna run the vagrant init command and we're gonna pass the Ubuntu slash trusty 64 parameter. Now this tells Vagrant what to use as a base operating system. What this command did was create a file named Vagrant file and really this is where the magic happens. This file, tells Vagrant what operating system we want and what software we want to install on it.

Let's take a look at the file. Now, this one here is one that I've already made a few changes to so yours will look a bit different. The Vagrant file is a ruby file. So if your familiar with the Ruby Syntax this is gonna be familiar to you. And if not, that's okay to cause it's mostly clear enough that you can reason through it. So you can see that by default this file is very well commented. These comments can help you in trying to understand a given section. Let's take a look starting at line 15. Config dot vm dot box equals Ubuntu slash trusty 64. Now this tells Vagrant that we want to use the trusty 64 OS from the Ubuntu user. There are a lot of different community created boxes that you can use as a base and you can find them all on HashiCorp’s website.

Now a quick note on security. These machine images are shared community images, so there is an implied level of trust when you use these. I like to stick with images that are from trusted sources, like Ubuntu or HashiCorp, though even that is not a guarantee of security. So, you're able to create your own images and specify the URL to those images in your Vagrant file and you can also upload them to the community if you want to.

Okay, back to the file. Let's take a look at lines 25 through 27. Here, we're mapping ports between our host and our guest operating system. The host is whatever OS your running on your computer and the guest is the VM that we've created. So, we can map shared folders as well. Check out line 42. This means that when you edit a file on your host operating system that's in a shared folder the guest operating system will also see those changes. Now this is an important part of this setup since it allows you to edit files on your host and see how they run on your guest.

Alright, since our Vagrant file is all set, let's start up the guest OS with the vagrant UP command. Vagrant UP will tell Vagrant to look in the current directory for a Vagrant file and if it finds it, it will use it to set up our VM. And if it doesn't, it will go up one directory and look for a Vagrant file there and it will keep doing this until it reaches a top level or finds a Vagrant file. Now, vagrant UP can take awhile especially since it's your first time running this because it needs to download the guest operating system. Let's fast forward to when it's complete.

Okay. Now that it's complete, we can connect into it and treat it like we would any other operating system. Let's connect in and see what we've actually created here. If you run the vagrant SSH command, it will connect into the Ubuntu VM via SSH. Now that we're connected in, let's verify that we have the OS that we wanted. And we can do this with the LSB underscore release command and passing in the minus a flag.

So here you can see that we're on a Ubuntu 14.04 command line. I mentioned previously that we would create an Ubuntu OS and run a python app. So, let's see the app and how it was set up. Keep in mind that this is where the difference is between my Vagrant file compared to yours will become evident, because you don't have this python app.

However; you should attempt to create your own app so you can better understand how to use these tools. For me to run my DJango app I need to change directories into the one that we mapped in our Vagrant file. Now that we've changed directories, I need to run the manage dot pi run server command to start-up the development web server. You may have noticed that it works without us having installed any of the dependencies such as virtualenv or even Django manually.
It did this for us, because we told Vagrant how to do it. In our Vagrant file, we told Vagrant to use the ansible provisioner. Vagrant allows you to specify what tool you want to use to provision the VM.

So if you are using a tool like Chef, Ansible, Puppet or Saltstack or some other tool in production, then you can use the exact same tool in development. This helps to further reduce differences between environments like production and development by ensuring the same versions of all software are used.

Configuration management tools like ansible are outside of the scope of what we're gonna cover in this course. But I wanna give you a run down of what an ansible playbook looks like. This is a yaml file which is just another markup language. The file here lists off the software that needs to be installed. The interesting stuff happens at line three where we start to find the tasks that need to be completed.

Each line that starts with minus name is a task. Some are apt get tasks to install software such as lines six through 15. And others are things like PIP installers. PIP is a python package manager. And here we're installing virtualenv and then we install some requirements that we need for our app and we install them into our virtualenv. Lines 20 through 27, install jenkins, a CI server that your gonna see later in this course. And lines 28 and 29 ensure the code to activate my python virtual environment whenever I SSH into the VM exists in the bashrc file.

It's worth noting, I'm not pinning any of the versions of software because this is just a demo, however; you should be pinning versions to ensure that your environments are using the exact same versions of different dependencies. So, when we typed vagrant UP, Vagrant downloaded our base VM and then used ansible to install everything that it needed to run our app. And I know that this ansible overview is pretty basic though, hopefully it conveys the value in having all of your requirements specified in code.

The final two things regarding Vagrant are the ability to stop and delete a VM. To stop a VM, you can type, vagrant halt on the command line and it will shut down the VM so you can re-start it later with the vagrant UP command. Now when you're done for good, you can type vagrant destroy and it will ask you if you're sure that you want to destroy it. If you say yes, then it will delete that instance of your VM. And that's Vagrant at a high level.

I know this isn't really part of the CI process, however; developing in an environment that mirrors production, will reduce bugs caused by environmental discrepancies.

In the following lecture, I'm gonna talk about version control systems and how they fit into CI.

Alright, let's get started.