14 Martie 2016
As programmers, we love to solve problems. We look at a problem and we figure out the steps that lead to a solution. We call these steps the algorithm. After we complete the algorithm, we hand it over to the computer, because it runs it faster and more reliable than we could do it. Then we are free to search for another problem. The following 3 tools allow us to do this for the development process itself. They take care of the repeatable, boring tasks and allow us to focus on building things.
cookiecutter creates a directory based on a provided template. That means we can create a template containing our desired project structure. This will have all starting settings, files, and dependencies. Then we create a starting project by running cookiecutter <our_template>.
Unlike Django's startproject command, cookiecutter can copy some files and directories instead of interpreting them as templates. That allows you to put Django or Jinja templates in your project.
cookiecutter also comes with its own long list of templates. So you can browse that and pick something, if you don't have a favorite project layout.
vagrant makes it easy to manage VMs. We only need a file named Vagrantfile with contents like these:
# -*- mode: ruby -*-
# vi: set ft=ruby :
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = "ubuntu/trusty64"
config.vm.hostname = "test-box"
config.vm.network :private_network, type: "dhcp"
config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--name", "test-box", "--memory", "1024"]
end
config.ssh.private_key_path = [
"~/.vagrant.d/insecure_private_key",
]
config.ssh.insert_key = false
config.ssh.forward_agent = true
end
After installing VirtualBox and vagrant, we can open a terminal, go to the directory containing Vagrantfile and run vagrant up. That will create a VM which we can log into by running vagrant ssh. When our work is done we can stop the VM by running vagrant halt. If we don't need the VM and want to destroy it, we run vagrant destroy.
Because VMs become so cheap, we can use one for each project. We can quickly create one to test some code, run some command or open a suspicious file. We can do all of our development inside VMs and keep our host OS uncluttered. This also allows us to develop on the same OS as the one we use in production. That way we avoid issues that occur because we developed on Mac and we run our service on Ubuntu.
vagrant and ansible working together make me smile. After we created the VM, wouldn't it be nice to have everything installed automatically? No more error-prone manual steps, no more outdated instructions lists.
Write these steps as ansible instructions and use them to install everything. Make it a point to only install things with ansible and not manually. That way you always keep the instructions up-to-date.
This also helps you minimize differences between development and production, since you run the same code on both targets. It also makes it easier for new people to hack on your project. They clone, run vagrant up and have a working development environment.
In the next article, we will build together a Django project that follows the 12factor app guidelines. Thus, we will have a starter project that follows industry best practices.