1

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?

Improve this question
2
  • the tests. What kind of tests, e.g. unit, integration? Why do you need vagrant? Why is docker not sufficient?
    – 030
    Commented Sep 12, 2017 at 22:34
  • 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.
    – AnoE
    Commented Sep 13, 2017 at 10:58

1 Answer 1

Reset to default
1

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

Improve this answer
1
  • 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).
    – AnoE
    Commented Sep 14, 2017 at 16:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.