Let’s talk about a common problem faced by developers and quality assurance engineers during a software development project…
Creating Development Environments with Vagrant
Let’s talk about a common problem faced by developers and quality assurance engineers during a software development project – which can turn into a chaotic mess if not properly understood and controlled.
Typically, when a software development team works on a project, team members do their coding on their personal computers. They assess any problems with the build or packaging process on their PCs, and they may also run unit tests in the same local environment.
When it’s time to do the first line of project testing, the individual team members deploy their code to the team development environment, which is where all the development code is tested against deployment failures and pre-defined test cases (which can be manual or automated).
With code from individual local environments loaded into the team development environment, there is a high risk that the development environment will become unclean. This is because there can be a lot of untested applications and versions within the environment, which also contain dependencies relating to third party libraries and software applications. It is also hard to know what exists over time due to the number of environment changes that take place.
Let’s explore the problem further. One of the problems with these unknown dependencies is that a particular test may pass the development environment and QA environment, especially if the QA environment had also undergone a number of changes over the time. However, if there is no pre-prod (pre-production) environment or some scenarios are not tested, there is a real chance that a bug will slip through the cracks into the final production environment where no tests are carried out.
Sometimes users or the customer will see the error/bug months later, however it is too late to pinpoint and determine which code change caused the issue. If a bug appears, it may not be reproducible in any environment unless an additional pre-prod environment had also previously been built with the exact same infrastructure setup and configuration.
Creating and maintaining a pre-production environment which will be identical to the production environment can be an expensive undertaking, only available to enterprise scale companies and projects. Often, this is not an option for SMEs. So how can SMEs get around this problem?
The solution is Vagrant.
Vagrant is a product developed by HashiCorp. It enables developers to quickly generate an environment similar to the production environment on top of a virtualisation environment such as VirtualBox, for example.
Vagrant allows developers to write script in Ruby (and other scripting languages such as Shell commands).
However, in order to do this successfully the production environment must have been generated via some sort of infrastructure-building scripting language (Infrastructure as Code — IaC) such as Shell, Ansible or Puppet. If this IaC script exists it can be used to help Vagrant generate a replica infrastructure in a VM (Virtual Machine) environment.
This means that when a developer runs the Vagrant script it will build/spawn a new VM which is as same OS (Operating System) as in the production environment and provides the same configurations.
Vagrant is a hugely beneficial tool
Using Vagrant as a development environment automation tool, has many benefits. Some of which are listed below:
- Vagrant provisions the same resources as in the production environment, on top of low cost hardware.
- Tests that cannot be run in production can be run in the Vagrant environment since they are identical.
- Developers can have multiple environments – similar to the production environment – at the same time for different tests, potentially with specific configuration changes to the environment for testing purposes.
- Developers can generate a Vagrant environment, carry out the testing and destroy it when done.
- It is possible to quickly generate production grade environments whenever necessary.
- Developers can store verified Vagrant code in a source code repository so all developers and QA engineers can reuse them.
- Vagrant code can be versioned in the source code management repository so that developers can replicate any previous version of an environment that the production environment has been through.
- Vagrant supports all the leading IaC provisioning tools such as Ansible, Chef, Puppet, Salt, Shell and Docker.
- Developers can reuse the production environment provisioning scripts to generate development/test environments with minor modifications (eg. URLs, host names and IPs etc. which are from the production environment)
- Vagrant brings automation to environments to introduce consistent and controlled provisioning.
- Vagrant is free (there is a cloud version available at cost).
It is worth noting that there will be some resources that developers cannot use within a VM, such as proprietary cloud platform original tools.
Furthermore, Vagrant based environments for performance testing cannot be used as the infrastructure’s resource power may be lower than the actual production environment. It is very important to build processes to overcome these problems mentioned above – which can be easily avoided with the help of smart technologies like virtualisation with Vagrant.
We hope you have found this Tech Guide useful. Look out for a seperate Guide coming soon, which will run through a full technical explanation of how to create a Vagrant file with Ansible, to provision a sample environment with Apache Tomcat web server running on Java v8 based on CentOS, a production grade infrastructure setup.