I would say that your choice of Vagrant was already a good start to what you are looking for, but now you need to delve into the chef or puppet to further automate the preparation process.
I think a good choice in your sceneraio would be to put both the Vagrantfile and the corresponding puppet manifest under version control as part of your project first. In addition, all configurations relating to this machine should also be included in version control and / or accessible through some kind of artifact repository.
Secondly, establish a rule in the team that will change (at least those that should live longer) on Wednesday, you need to check if they are considered ready for other team members.
Regarding your second question and returning to my discovery: Puppet (what I like) or a chef are your tools of choice and can save you and your colleagues a lot of work in the future. I will stick with Puppet here, since I don’t know that the Chef is too good.
With a puppet, you can control everything you want, install packages, change configurations and ensure the operation of certain services or even the fact that the system has the state in which you want. Even better, if you or another member of the team did some malicious spells in your box, you can simply undo the changes in your Vagrantfile / Puppet manifest, enter
vagrant destroy && vagrant up
and the field easily returns to the latest version state.
For example, take the following manifest file:
package { "mysql-server-5.1": ensure => present } file { "/etc/mysql/my.cnf": owner => "root", content => "http://myrepository.local/myProject/configurations/mysql/my.cnf", require => Package["mysql-server-5.1"] } service { "mysql": ensure => running, subscribe => File["/etc/mysql/my.cnf"], require => File["/etc/mysql/my.cnf"] }
What this means is that it first of all checks the mechanism of the OS package in your field (the names in the example assume recent Ubuntu) if the package "mysql-server-5.1" is installed, and if not, I will install it. Through the "require" attribute, the second directive will be executed after the first (and only if it works), changing the MySQL configuration to the one you also checked and / or published somewhere that you can contact (this can also be put in that same folder as Vagrantfile, and then will be available in the box under / vagrant). The last step, which will only be performed again when the configuration is changed, will ensure that the mysql service is started and started, or restarted if it was already started when the configuration was changed.
Now you can connect this manifest in your Vagrantfile:
Vagrant::Config.run do |config| config.vm.box = "lucid32" config.vm.box_url = "http://files.vagrantup.com/lucid32.box" config.vm.define "node1" do |cfg| cfg.vm.network "10.23.5.11" cfg.vm.provision :puppet do |puppet| puppet.manifests_path = "manifests" puppet.manifest_file = "node1.pp" end end end
With all the changes, in addition to the "trial stuffing" made in such an environment, all the command boxes guarantee that the same setting will be easily and reproducible only at hand.
I personally wanted to try the material on the box manually, and when I found the correct setup and customization, translate it into the Puppet manifest so that it was ready for future use and sharing with team members.
Since Puppet (and Chef also) can manage almost everything you need (users, cron jobs, packages, services, files, ...), this is a good choice for such problems, and you can even use configurations to provide intermediate or test environment later if you decide. There are many more options with Puppet, and reading a language guide should give you an idea of what else you can do with it.
Hope I can help :)