A couple development environments worth considering
Every Digital Foundry software engineer has their own development environment for their project. It is a common best practice used in the industry, and we have been following it for 20 years. In the past, this meant every time an engineer moved from one project to another they had to tear down the development environment they had configured on their machine and completely rebuild it to match the environment for their new project. It was costly and time consuming, so Digital Foundry decided to go virtual. Digital Foundry is continuously evolving and evaluating new technology as it hits the market, so over the years we’ve used a number of different tools to virtualize our development environments. Following are the two tools we’ve most commonly used over the past six months.
What is it? Vagrant is a tool for building complete virtual development environments. HashiCorp developed Vagrant as an open source project under the MIT license. Vagrant is widely used and supported by the open-source community with an option to purchase professional training from the core team at HashiCorp.
Why Digital Foundry uses it: Vagrant is about speed and efficiency. It allows our developers to build a complete development environment that can be easily shared with other developers on the team. We also use it to facilitate adding new members to the development team as well as updating the environment as the project changes.
How can it help you? The faster your development team can spin up a new local environment, the faster they can get back to writing code. Vagrant also solves the historical problem of having code work on one developer’s machine but not on another.
Great, but aren’t there risks? It depends on your needs. If performance of your development environment is a consideration, Vagrant may not be the solution for you. The intent of Vagrant is to support development by using virtual environments, and virtual environments will never be as fast as stand-alone machines. They can bog down the developer’s machine depending on the number needed and their memory requirements. If this is an issue, you will likely need to invest time to improve performance by combining virtual machines, optimizing the base image, or looking to move to a container solution such as Docker.
Learn more @ http://www.vagrantup.com
What is it? Docker is a CaaS (Container as a Service) that provides agility for development teams. It is an open-source product built by Docker, the company, under the Apache License Version 2.0. It offers both an open-source community for support and the option to purchase support directly from Docker.
Why Digital Foundry uses it: Containers allow our developers to quickly spin up environments that match the services running in our client’s production environment, so code is developed for and tested against the same configuration throughout all environments. This provides Digital Foundry a lightweight system that isolates processes from one another to provide security, performance, and ease of deployment. Docker uses a Dockerfile to describe the container configuration, giving us a repeatable and archivable description of the software necessary for a container. We can easily launch new containers, so we will often launch one to run unit tests and/or integration tests. Docker provides multiple tools to facilitate development. Two in particular that Digital Foundry finds helpful:
- Docker Machine abstracts out the differences between Windows and OS X.
- Docker Compose provides orchestration between dependent containers, allowing the developer to specify container dependencies and parameters.
How can it help you? Docker helps speed up and standardize environment configuration, which reduces bugs that would result in differences in environments. It can give you, as a product owner, a level of comfort that once the container works in one environment, it will work in any environment.
Great, but aren’t there risks? Yes, but maybe not for very long. There are a number of things to consider before adopting Docker. The use and management of application containers is relatively new, so it’s not well understood by the traditional ops, information security, development and auditors community yet. The flexibility of containers makes it easy to run multiple instances of applications but may indirectly lead to Docker images that exist in varying states of security patching. There is also the possibility for a Docker image to be bloated if the owner bases it on a full OS rather than a pared down system that only provides the necessary services.
Learn more @ http://www.docker.com