Answers: <p>Vagrant, in this case, would simply add a lot of unnecessary overhead into your testing environment. You can create containers that quickly test specific groups of functionalities and paste the results somewhere. Your team won't spend much time learning how to start these containers as it is usually a simply command. Most of changes are going to be done inside the code, not into the testing environment. But if you need to change the test environment, the Dockerfiles must be in an easy to access place. You could also automate the build process of containers linking the Dockerfile (e.g. from a GitHub repository) into the DockerHub or Store.
  I can't see a reason here for not going into Docker. This knowledge will be more usefull for your team than Vagrant skills.</p>
  
  <p>You can read more about it here: <a href="https://stackoverflow.com/questions/16647069/should-i-use-vagrant-or-docker-for-creating-an-isolated-environment">https://stackoverflow.com/questions/16647069/should-i-use-vagrant-or-docker-for-creating-an-isolated-environment</a></p>
  
Answers: CC BY-SA 3.0
Answers: 2017-09-14T16:42:04.357Z
Answers: Thank you, some reading I did meanwhile leads me to the same results; I was initially not quite clear abou the fact that Vagrant is (mostly/only?) concerned about Virtual Machines and is more of an alternative to Docker instead of something which naturally should go with it (assuming, as in this case, that the devs actually already have their development environments already).
Answers: AnoE
Answers: CC BY-SA 3.0
Answers: 2017-09-14T12:29:22.187Z
Answers: 2017-09-14T12:29:22.187Z
Answers: Felipe de Macêdo
Body: <p>I have a Ruby on Rails application that has been around for a while, and implemented completely classical, so far. Everything is fine; but since the number of environments we are deploying to (testing, QA, several production envs) have grown, I decided to dockerize the thing.</p>
  
  <p>A side effect should obviously be that new developers get on board quicker.</p>
  
  <p>At the moment, I have made a Dockerfile to build the application and run it; I am happy, everything is fine. I am now pondering how to move on:</p>
  
  <ul>
  <li>Either make it so that the tests can be run by a simple docker command as well - so that the daily development loop simply consists of edit-rebuild-run-tests (or, for that loop, we'd probably rather just mount/bind the sources that are actually being edited by the dev outside of the container, so we save the explicit "rebuild". Nothing needs to be precompiled etc. for running the tests anyways.).</li>
  <li>Or use something like Vagrant to streamline the development environments, and don't really use docker for the actual edit-test cycle.</li>
  </ul>
  
  <p>I am strongly tending to the first option (i.e., KISS), but I have little experience working with this. I can't really speak on the second as I have no real experience with any of those tools like Vagrant that focus on the developers perspective.</p>
  
  <p>The other developers have no particular experience with any of these tools, so whatever I pick/suggest should better be pretty non-invasive. Everyone has their happy, well-configured VM to develop in, so far. We don't really encountered any problems with developer VMs diverging, or something like that (this being Ruby, after all).</p>
  
  <p><strong>Questions:</strong> is there anything wrong with going for my first scenario? Are there <em>huge</em> benefits introducing something else aside of docker at this very early stage of our team digging into DevOps tools?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-09-12T22:34:14.157Z
Comments: `the tests`. What kind of tests, e.g. unit, integration? Why do you need vagrant? Why is docker not sufficient?
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2017-09-13T10:58:52.853Z
Comments: Cucumber scenarios, self-sufficient (no outside interfaces etc. needed). I am asking *whether* I should start off the whole DevOps experience for the team with something like Vagrant, or just let everyone get used to Docker first. There are a lot of products out there, and it is not trivial to find a working approach.
Comments: AnoE
Tags: <docker><vagrant><learning>
Title: Start dev with purely docker, or something like vagrant (in a to-be-dockerized application)?
UserDisplayName: AnoE
ThreadText: # Start dev with purely docker, or something like vagrant (in a to-be-dockerized application)?
  
  (Asked by: username_0 on 2017-09-12)
  
  I have a Ruby on Rails application that has been around for a while, and implemented completely classical, so far. Everything is fine; but since the number of environments we are deploying to (testing, QA, several production envs) have grown, I decided to dockerize the thing.
  
  A side effect should obviously be that new developers get on board quicker.
  
  At the moment, I have made a Dockerfile to build the application and run it; I am happy, everything is fine. I am now pondering how to move on:
  
  * Either make it so that the tests can be run by a simple docker command as well - so that the daily development loop simply consists of edit-rebuild-run-tests (or, for that loop, we'd probably rather just mount/bind the sources that are actually being edited by the dev outside of the container, so we save the explicit "rebuild". Nothing needs to be precompiled etc. for running the tests anyways.).
  * Or use something like Vagrant to streamline the development environments, and don't really use docker for the actual edit-test cycle.
  
  I am strongly tending to the first option (i.e., KISS), but I have little experience working with this. I can't really speak on the second as I have no real experience with any of those tools like Vagrant that focus on the developers perspective.
  
  The other developers have no particular experience with any of these tools, so whatever I pick/suggest should better be pretty non-invasive. Everyone has their happy, well-configured VM to develop in, so far. We don't really encountered any problems with developer VMs diverging, or something like that (this being Ruby, after all).
  
  **Questions:** is there anything wrong with going for my first scenario? Are there *huge* benefits introducing something else aside of docker at this very early stage of our team digging into DevOps tools?
  
  **Tags:** docker, vagrant, learning
  
  > **Comments:**
  > **username_1**: `the tests`. What kind of tests, e.g. unit, integration? Why do you need vagrant? Why is docker not sufficient?  
  > **username_0**: Cucumber scenarios, self-sufficient (no outside interfaces etc. needed). I am asking *whether* I should start off the whole DevOps experience for the team with something like Vagrant, or just let everyone get used to Docker first. There are a lot of products out there, and it is not trivial to find a working approach.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-09-14. Score: 1 | Accepted answer
  
  Vagrant, in this case, would simply add a lot of unnecessary overhead into your testing environment. You can create containers that quickly test specific groups of functionalities and paste the results somewhere. Your team won't spend much time learning how to start these containers as it is usually a simply command. Most of changes are going to be done inside the code, not into the testing environment. But if you need to change the test environment, the Dockerfiles must be in an easy to access place. You could also automate the build process of containers linking the Dockerfile (e.g. from a GitHub repository) into the DockerHub or Store.
  I can't see a reason here for not going into Docker. This knowledge will be more usefull for your team than Vagrant skills.
  
  You can read more about it here: <https://stackoverflow.com/questions/16647069/should-i-use-vagrant-or-docker-for-creating-an-isolated-environment>
  
  > **Comments:**
  > **username_0**: Thank you, some reading I did meanwhile leads me to the same results; I was initially not quite clear abou the fact that Vagrant is (mostly/only?) concerned about Virtual Machines and is more of an alternative to Docker instead of something which naturally should go with it (assuming, as in this case, that the devs actually already have their development environments already).  
  
  ---
  
  