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

-
You have one or more services to deploy. (If not, what are you doing -here?)
-
-
Your services are tracked in source control. (If not, go sort that out, -then come back. No, seriously, now.)
-
-
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?)
-
-
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.)
-
-
For each service, in each environment, there is a canonical series of steps -that produce a “deployed” system.
-

Decide what code should be deployed. (This is a version control activity.)
Get the code onto the fucking server.
Decide what configuration values should be deployed. (This is also a - version control activity, though possibly not in the same repositories as - the code.)
Get the configuration onto the fucking server.
Get the code running with the configuration.
Log to fucking syslog.
When the machine reboots, make sure the code comes back running the same - configuration.

- - - -

- - - - - -