But we do need to be able to control the VM configuration in git. Because of that, we don't currently want to include any development environment code in our actual project repositories. The VM must be independently version-controllableĬhromatic is a distributed team, and I don't think any two of us use identical toolchains. So I wanted to see if I could configure Drupal VM to work within these parameters: 1. Since I've worked with various VM-based solutions before, I had some fairly specific requirements, some to do with how I work, some to do with how the Chromatic team works, and some to do with the kinds of clients I'm currently working with. (Ansible also relies on YAML for configuration, so it fits right in with Drupal 8).
#Drupal vm alias software#
This was immediately interesting to me, partly because Ansible is the tool we use internally to configure project servers, but also because the whole point of configuration management is to reliably produce identical configuration whenever the software runs. It’s based on Vagrant and another configuration management tool, Ansible. Drupal VMĮventually, I found Drupal VM, a very well-thought-out virtual machine-based development tool.
Even the virtual-machine based solutions often suffered from the same kinds of problems - even when I experimented with version-controlling critical config files such as vhost configurations, php.ini and my.cnf files, and building servers with configuration management tools like Chef and Puppet. Typically, I would encounter problems with stability when multiple sites on one server needed different configurations, or problems customizing the environment enough to make it useful for certain projects. That's not even a complete list - I know I've also tried other solutions from the wider LAMP community, still others from the Drupal community, and I've rolled my own virtual-machine based servers too.Īll of these tools have their advantages, but I was never wholly satisfied with any of them.
#Drupal vm alias full#
0 kommentar(er)
