Yes it is practical. First start by attempting to achieve your goal by hand, using written instructions that everyone on the team follows. Note how it went. Note lessons learned. Note unexpected details. Vagrant may only achieve that you want it to achieve, so if you can't do it by hand, then Vagrant can't do it for you, either.
After doing a couple of "development rollouts" like this, migrate your set up to Vagrant. Read all of the literature. Take good notes. Perhaps even read it again. It is deceptively simple because it "just works". If you rush through it, and rush into it, then you will suffer quickly. Do a few rollouts using Vagrant. Perhaps have another team, or two try it and see how it goes. Capture lessons learned. Revise your setup. Now scale it to 3-4 teams. At this point, you are an expert. You know the "Vagrant workflow". Now is the time to read up on Packer, too. They may play quite nice together, thought it won't make much sense until you get your feet wet. Grant Rettke | AAAS, ACM, ASA, FSF, IEEE, SIAM, Sigma Xi [email protected] | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson On Mon, May 19, 2014 at 9:25 AM, Hemen Kapadia <[email protected]> wrote: > Hello all, > > I recently came to know about Vagrant and was impressed about its > capabilities and simplifying some of the development workflows. I have > started reading more about the same but i need some strategic advice from > the more experienced users on this group. > > The capability that particularly impresses me is the ability to setup a > *single > standardized development environment* for all the team members such that > when a new member joins they just need to close a repo and issue a vagrant > up. > > My setup and vision is as follows > > - Host and guest are both Ubuntu 12.04 LTS. > - Vagrant with Virtual box. > - Intent to use for development only - but to follow and learn > practices that are scalable (in case the process needs to be replicated to > a team of 100+ not necessarily geo-colocated) > - The application would be a Web front end talking to a J2EE backed > using RESTful web services. > > In such a scenario, I would want > > - only the IDE and the Browser to be running on the host - *such that > each developer can have it as per their preference.* > - all build tools like maven, maven repo, dependencies, yeoman stack, > database, app server should be on the guest- *something which should > be standard.* This is the possibility that impresses me the most. I > also want the actual build to happen on the guest, which will then get > deployed in the app server running in the guest. > > Is this a practical vision to have ? Any best practices or documents one > can guide me towards. > > Also in such a setup since the entire maven repo and dependencies are in > the Guest OS, but I am using Eclipse on the Host OS for editing - how can > one assure of code completion and dependency resolution that is important > for Eclipse to work too? > > > Awaiting guidance. Ready to be redirected to some reference reading - if > that needs to be done first before posting on this forum > > Thanks for your help. > > Hemen. > > -- > You received this message because you are subscribed to the Google Groups > "Vagrant" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Vagrant" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
