Open usernamenumber opened 9 years ago
The usernamenumber/swag branch in the provision repo now has the beginnings of automated deployment instructions for a swag dev environment. As of this writing it only sets up learning locker, but that should be the most difficult part. At my next opportunity to spend time on this, I'll set it up to deploy swagportal as well. Once that's done, new developers should only need to clone the provisioning repo, change a couple of settings, and then run vagrant up
to get everything they need to start hacking.
Hi,
Working with vagrant this way is a new thing for me. I'm open for new things though, so this is not something bad, but also maybe I can provide some (hopefully healthy) skepticism. Vagrant adds one extra moving part, one extra layer of abstraction, one extra thing that can go wrong and one extra thing I don't have control over. I will accept this if it "Just Works", so I feel that it is important that we get it into a state where this is the case. For me it didn't on the first try. And anything other than the first try is not acceptable for this, I would argue, and might discourage new developers...
I did the following:
git clone --recursive https://github.com/tunapanda/provision
cd provision/
vagrant up
And got the following error:
micke@micke-X360:~/repo/provision$ vagrant up
There is a syntax error in the following Vagrantfile. The syntax error
message is reproduced below for convenience:
/home/micke/repo/provision/Vagrantfile:31: syntax error, unexpected ':', expecting kEND
config.vm.provision "shell", inline: $script, keep_color: true
^
/home/micke/repo/provision/Vagrantfile:31: syntax error, unexpected ':', expecting '='
config.vm.provision "shell", inline: $script, keep_color: true
^
/home/micke/repo/provision/Vagrantfile:83: syntax error, unexpected ':', expecting kEND
config.vm.network "private_network", ip: "192.168.33.20"
Should say also that this is feedback, not criticism... Please tell me how I can help out to get it into the magic "Just Working" state...
This includes Learning Locker and the Swag portal (or equivalent).
The provisioning repo contains Ansible roles (a role is a set of instructions for setting up a service automatically) that can be used to deploy important services. I propose that it's worth some extra effort up-front to create Ansible roles for everything we need on staging.tunapanda rather than configuring it manually, since once we have the setup automated with Ansible, we can easily re-deploy, deploy to a local server for dev and testing, etc.
A while ago I started (but never completed) work on roles for swag, learninglocker, and composer, on which learninglocker depends. These are part of a very old branch, and will need to be merged to a newer branch before further work can be done. For now I'm just linking to them as examples.