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?

AnoE
  • 4,936
  • 14
  • 26

1 Answers1

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

Felipe de Macêdo
  • 136
  • 2