From a669b5d12c096925337e1cc7ed8600e5b8a4feda Mon Sep 17 00:00:00 2001 From: Owen Jacobson Date: Mon, 29 Oct 2012 23:35:11 -0400 Subject: Forward-engineering `git-deploy`, one concept at a time. --- wiki/devops/autodeploy.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 wiki/devops/autodeploy.md diff --git a/wiki/devops/autodeploy.md b/wiki/devops/autodeploy.md new file mode 100644 index 0000000..ee05298 --- /dev/null +++ b/wiki/devops/autodeploy.md @@ -0,0 +1,25 @@ +# Notes towards automating deployment + +This is mostly aimed at the hosted-apps folks; deploying packaged software for +end users requires a slightly different approach. + +## Assumptions + +1. You have one or more _services_ to deploy. (If not, what are you doing +here?) + +2. Your services are tracked in _source control_. (If not, go sort that out, +then come back. No, seriously, _now_.) + +3. You will be deploying your services to one or more _environments_. An +environment is an abstract thing: think "production", not +"web01.public.example.com". (If not, where, exactly, will your service run?) + +4. For each service, in each environment, there are one or more _servers_ to +host the service. These servers are functionally identical. (If not, go pave +them and rebuild them using Puppet, Chef, CFengine, or, hell, shell scripts +and duct tape. An environment full of one-offs is the kind of hell I wouldn't +wish on my worst enemy.) + +5. For each service, in each environment, there is a canonical series of steps +that produce a "deployed" system. -- cgit v1.2.3