Pattern - Manual Deployment

Developers/operators configure a system by hand, deploying all applications using manual operations (command line/GUI). In a 'well-managed' manual deployment process, the exact steps to deploy a system are noted down.

Features

• Developers/operators build systems through manual operations.
• Scripts and GUIs aid in this task.

Advantages

• It's very easy to start off.
• Total control of the target system.
• Competent individuals are capable of dealing with all problems encountered.
• Most single-host systems support some form of manual deployment, with appropriate tooling.
• Implicit choreography of deployment actions (i.e. only one action at a time is performed).
• Learning to diagnose the state of the machine is a valuable skill.

Disadvantages

• It doesn't scale to multiple machines.
• It doesn't scale to large operations teams.
• It is hard to repeat reliably. Even if every step is documented, the risk of steps being performed in the wrong order is high.
• There is no automated diagnostics of which part of the system is failing.
• It isn't economic, even on a single machine.
• No formal way to transfer the experience from the developers to the operations.
• No automated rollback of changes.
• It makes developers/operations people think that manual deployment is the way they should be deploying.

Manual deployment is the default deployment practise of most systems, even though it is broadly accepted as the worst possible way to to do it. It's certainly a good way to learn how systems work, and how to get software on them working, but it leads everyone astray

When developers build a system, they forget some of the stages, and the initial state of their boxes. The production servers need to be set up to mimic the environment, and when things fail, we are reduced to guesswork to determine what has gone wrong. Sometimes it is errors of omission, sometimes it is an ordering problem.

The replication problem leads to one of scale. It's expensive to set up one system, very expensive to set up tens of machines. Unless the team practises Pattern - Machine Cloning, there is no way to manage any cluster of more than a few hosts.

The other issue is rollback: automated deployment tools can not only deploy software, they can roll back software and state changes to the machine.

SmartFrog Support

SmartFrog actually supports manual deployment, specifically manual deployment of SmartFrog descriptors. Rather than use brittle shell scripts or simple GUIs to deploy systems, the operations/developer team can run the .sf files of their choosing, either from the command line or the GUI. This gives them the ability to hone the individual pieces of a large system deployment, and the flexibility to deploy the pieces that they want. It also allows them to roll back the deployment, without writing separate teardown scripts.

The critical benefits arise is when the larger system is to be deployed, and the deployment is to be automated. The individual deployment descriptors can be aggregated to produce a larger deployment, one where the ability to share configuration options is still possible.