State-driven deployment

With a state-driven deployment tools, one provides the description of the desired state of the system, and the operations needed to keep the system in that state. For example, you could declare that an entry must exist in the password file, and either the action to take when it isn't there is to add the entry, or the tool can contain the logic to know that the correct way to add an entry to the file is to append a line.

Features

• A declarative description of the desired state of the system is authored (somehow)
• Configuration Management agents push the system into the desired state -and keep it there.

Advantages

• The system becomes self-righting: if the configuration of machine does not match the specification, the agent will apply the changes needed to put it back into the desired state.
• Complex system state can be built up by aggregating smaller state descriptions.
• System monitoring is integrated with deployment.
• The description of the system state can be higher level than procedural operations.
• [Preflight] checks may analyse the description and look for errors in advance.
• System Analysis may review the target system and report what changes will be applied -in advance of making any of the changes.

Disadvantages

• New languages are needed to describe the state of the system.
• New tools are needed to push the system into the desired state; developers may be unfamiliar with them.
• It's not clear what 'undeployment' is in this context. Once the state management tools have pushed a system into a specific state, there's no real notion of rolling it back.
• The agent needs to be running at all times.
• The aggregate state of the system may not actually be consistent. That is, one part of the description may push the system into one state, another part pushes it into another. What happens in this situation is dependent upon the specific implementation. It may iterate round all possible states, or it may detect the inconsistencies and report them.

SmartFrog support

The SmartFrog language can be used to describe the states of target systems, and the [SmartFrog Daemon] act as the configuration management agent. One subtlety is that while SmartFrog components can detect when they are not in a specific state, they do not normally automatically apply the changes. Instead they report the failure to their parent component. You need to use the retry component to undeploy then redeploy the component(s).

Other tools

• bcfg2 is one open source example of this.