This is not an article about cooking. However, working with Chef has much in common with cooking and it’s not just a matter of terminology. Adding cookbooks and recipes is a bit like adding ingredients and spices to soup – the soup being the servers in this case, but that’s not what this article is about, so let’s get to the point.

What for?

That’s right, “What for?” is the fundamental question in this case. There are a lot more of them. Does it make sense to introduce automation if every programmer should be able to configure the development environment him/herself? What do we achieve by automating development environment? Will the time spent on automation pay off?

We can ask much more questions like that. Some questions and answers are purely philosophical and probably will remain as such. Below, I’m going to try to present the pros of automation and later I’m going to describe how we did it.

Pros

Like any automation, this one was aimed at automating certain processes. I read somewhere once that it pays off to automate (program) processes, in which the time spent on automating pays off after a year. Is that so in this case? I don’t know exactly, we conducted no specific estimates, so my statement that it pays off at the time of introducing a second person in the project is only subjective.

In any case, the time saved after introducing other people to the project is substantial. They get already prepared environment “out of the box”. In the case of simple projects it may not be so noticeable, but in the case of projects requiring specific settings and applications it may even be a matter of few days, especially if the secret knowledge concerning the project has not been saved or the developer of applied solutions forgot it.

It’s another advantage. Knowledge about the project, its configuration is stored and versioned (the repository of cookbooks is in git) even if they’re only lines of code.

Lines of code and all that’s associated with automation formation happen in Ruby. Ruby is already a very popular programming language – many already know it, and if not, you can learn it very quickly. Therefore, we don’t need to learn a new language, which we won’t use anywhere else.

Another major advantage of the use of virtual machines is the possibility of mapping production environment.

How does it work?

The principle is very simple. Imagine that the whole process of application development happens on the external server. This is exactly what happens in this case.

There’s only one small “but” –  this server is on your computer. What possibilities this gives us? We can use the benefits of shared directories, thus any programmer can use his/her favorite editor, provided that it’s Vim :)

How did we do it?

Ingredients

  • 1 Chef Server
  • 1 Chef Client
  • 1 Virtual Machine
  • 1 Knife

Preparation

Set up the Chef Server and using the Knife load the cookbooks. Start the Chef Client on the Virtual Machine, and there you go, a working development environment.

The recipe located above briefly describes how we created the automation of development environment. Technical details of the whole automation process are a topic for a separate article. I will discuss only briefly the ingredients we used and mention the challenges that arose during the work.

Chef Server

It’s an application written in Ruby and Erlang, created to manage servers. It does exactly so – manages virtual machines or servers for developers. The application has an administration panel available through the browser, which greatly facilitates the daily work.

Knife

It’s a tool available from the command line interface, linking the local chef repository (cookbooks, roles, etc.) with the Chef Server.

Virtual Machine

This tool probably needs no introduction to anyone. I would only add that in the automation virtualization solutions provided by VMware were used.

Chef Client

It’s an application that runs in a virtual machine mandated to follow all instructions contained in cookbooks assigned to a particular machine. It installs all the components necessary to a programmer.

The combination of these elements allowed us to automate development environment. Everything ran almost automatically. The biggest challenge was to authorize virtual machines. The programmer adding a new machine has to authorize it in the Chef Server. Originally, we used the Knife bootstrap to do it, however, the chef repository was required. The quantity of ingredients that you had to connect posed a problem for people starting work with this environment. It turned out that the best and easiest way is a simple shell script.

What did we gain?

Time! Which shouldn’t come as a surprise, since that was the reason we went through all the trouble. Additionally, you can say that we gained a “peace of mind”, almost no-one asks us how to set up a project, the secret knowledge has not disappeared soon after the introduction of the last person. Now things just happen on their own, and the introduction of a new programmer or frontend specialist takes only a few moments.

Such automation of development environment actually works, not just as a new toy in the hands of novelty-seeking developers.

Are you interested in automating your development environment? Get in touch with our team of experts to learn more about automation! 

Mateusz Koszutowski

Senior PHP Developer at Divante eCommerce Software House

Share your comment