We must also give proper consideration to monitoring and logging hoovering at this point.

That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. I should probably digress here for a moment and explain why. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. I will explain it on 'live-example' of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is )). Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ). Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms.

Teamcity octopus