There is an infamous, much repeated dialogue between Development and Operations team that goes:
- Operator (with urgency): “The application you’ve developed doesn’t work”
- Developer (frustrated): “It works on my laptop”
- Operator (sarcastically): “Shall we add your laptop into production?”
- Developer (under breath): “$%£@$% !”
The moral of the conversation is the importance that developers understand how their application is going to be deployed-into, and run-in, and perform-in the production environment (a key tenet of DevOps).
Whilst the conversation is still telling, I believe now, more-than-ever that developers have the chance that what works on their locally laptop is genuinely production-ready.
Historically a developer’s machine would contain:
- an operating system completely different to production (e.g. Mac OS or Window XP)
- a tool for editing code (somewhere on the spectrum from a text editor like VIM to an Integrated Development Environment (IDE) like Eclipse)
- a local environment for testing the code (often consisting of an application server within the IDE)
The local environment could be further characterised as:
- Using a different version of the application server to production
- Running as the developer’s user account
- Having access to the developer’s home directory and the version control repository
- Excluding any other application components than the primary one under development
- Almost entirely free from security measures e.g. password encryption
However this no longer needs to be the case.
Virtual Box makes it possible to run a local virtual instance of exactly the same operating system as Production.
Vagrant makes it easy to manage Virtual Box from the command line (and even use version control e.g. Git to manage the configuration of this).
Online repositories of virtual machine images e.g. www.vagrantbox.es make it quick to get started with a the virtual machine that you need.
Box image creation tools like Veewee and Packer make it easy to create your own box images (and if you are using a cloud provider supporting machine images like AWS, you can even use these boxes in production.
Automated Configuration Management tools like Puppet and Chef mean that not only can you set up your local virtual server(s) to match the configuration of the Production environment, you can do it using exactly the same scripts that will be used in Production.
Integration with cloud providers (e.g. from Vagrant) mean that you don’t even need to stop when your local laptop runs out of steam.
Challenge yourself and your development teams to do a better job of development environments using the above tools (and more), and hopefully this infamous dispute will become a thing of the past!