Vagrant seems like a universal thumbs up then. Cool. Can any of you speak
to what the ramp up / setup effort might be?




On Fri, Aug 15, 2014 at 10:06 AM, David Skinner <[email protected]>
wrote:

> We also use Vagrant everyday here where I work. For the same reasons
> Richard Miller gave. We do have a different configuration though. Our
> project has many domains pointed to our code base. Our provisioning sets up
> each project with a specific private IP address. 10.0.0.2. We then use
> dnsmasq and configure a custom TLD to point to the vagrant machine. The
> dnsmasq config uses a wildcard to route all traffic on our local machine
> using the custom TLD to the IP address of our vagrant machine. Our TLD is
> ".sc". So I can simply type something like clientdomain.com.sc in my
> browser and dnsmasq will route it to my vagrant box, loading the clients
> version of our site. This helps us as we bring on new clients all the time
> using their own domain. We have a table in the database that stores the
> clients info along with their domain name. We then refer to that table with
> a provisioning script to dynamically generate the Apache configs for the
> vagrant environment, automatically appending the .sc TLD.
>
> Before we use Vagrant, it could take a person 1 - 3 days to get their
> environment set up correctly. Now with Vagrant, we can have someone up and
> running in about an hour. You can also use Vagrant to provision EC2
> instances on Amazon if that's something that would be helpful.
>
> Another use case where Vagrant came in super helpful was a PHP version
> upgrade. We simply cloned a new copy of our project. Made an upgrade
> branch. Changed the provision scripts to install a newer version of PHP.
> Pushed the branch up to origin. Then each developer could clone the
> project, switch to that branch, then run vagrant up to provision that
> environment with the new version of PHP. Then we all worked together to
> make the code compatible with the newer version of PHP. Since we had this
> second clone of the codebase, we could easily turn of the newer machine and
> turn on the old one to perform any emergency bug fixes that were needed on
> the Production servers.
>
> We use Debian 7 as a base.
> We use a collection of shell scripts to provision the environment. Though
> when time permits we'd like to move to something better like Puppet.
>
> dnsmasq: http://www.thekelleys.org.uk/dnsmasq/doc.html
> AWS EC2 integration: https://github.com/mitchellh/vagrant-aws
>

_______________________________________________

UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net

Reply via email to