It works on my Machine: OpsDev, Engineering Kick Ass Development Environments using Docker on Vagrant
Have you ever heard a developer or yourself say “But it works on my machine!”? This defence is usually heard after a C.I. or deployment failure, or after a new team member has been trying to get his PC set up for the project after a week of trying.
This talk aims to impress on the audience that DevOps is not simply a one way street with developers imparting their hard won skills and best practice on Ops, but also shows how Dev teams can directly benefit from the DevOps discipline by creating and managing their development environments using DevOps tools.
The problem is that there are normally quite a few undocumented or forgotten set-up steps or conflicting tools on a dev box.
It’s time to take back some professional pride, and engineer a solution.
In this presentation I introduces a way to systematically capture all the missing steps in an executable specification document (aka a software program). This allows for a much more robust way to develop systems.
In particular the audience will learn how to spin up isolated development environments using Docker as a Vagrant “box” that require almost zero procedural overhead and can be used just as easily as running the development natively on their own PC but with the benefit that it can be repeated by anyone, including themselves 6 months down the line when asked to do a maintenance fix, without breaking or ruining their current working environment.
There is a lot of confusion around Vagrant and Docker, what they are, how they differ and why would someone pick one over the other? The vagaries of Vagrant and the dastardliness of Docker are discussed and I will explain the sweet spot I settled upon and how it solved my problems.
I have prepared a working example in Github to show that this stuff “works on my machine” and it will work on yours too.