I thoroughly disagree with those who are saying that for small
installations, it's less time-consuming to do things manually. A
deployment/provisioning system gives you reproducibility - an executable
record of how to re-create a server configuration or re-run a deployment
without missing anything.
Speaking of CI and deployment -- Does anybody know of an open source
implementation of the idea described in this blog post? Maybe somebody
has one and could open-source it?
http://googletesting.blogspot.co.uk/2011/06/testing-at-speed-and-scale-of-google.html
We're not all google, but overki
I don't know any scenario like that: usually dependencies are frozen (and
tested) separately in a "release". It makes the whole process simpler.
Possibly they wanted to test how far they can push TDD, to be able to do
testing on the entire code (apps + libraries) using the development branch (al
Daniel, who are you disagreeing with? Everyone here agrees on
automation, I think.
- Andy
On 18 May 2013 12:24, Daniel Pope wrote:
> I thoroughly disagree with those who are saying that for small
> installations, it's less time-consuming to do things manually. A
> deployment/provisioning sys
Just to second what Daniel is saying, I have found that generally we get much
higher quality outcomes using a deployment/management system (puppet/chef/salt)
over SSH/shell commands, such that I would even use it to manage repetitive
tasks on a single machine.
Kris
--
Kris Saxton
e: k...@autom
