Reply to comment

We really really really need this! I'd love to take a look at some early development stages. I agree with the gaps identified. In terms of rollback, it may be possible to do a rollback if we approach it as one would approach undoable changes in any document editing interface. Here are the basics we would have to consider:

Assumptions:

1. Individual changes would have to be reversible
• Would need to prepare an SQL statement which would undo each individual SQL statement included in the deployment, e.g. a DELETE for every INSERT, a REPLACE for every REPLACE
• Would need to retain a backup copy of each file to be replaced in the deployment
2. Changes would have to be serial, must be recorded in a journal/log, and the order of operations must be strictly maintained.
3. Compound changes would need to be defined which are "atomic", i.e. they must be done completely otherwise an automatic rollback will occur and failure will be the result.
4. A hierarchical model of deployments would need to be defined to enable the above.

With these basic assumptions we can imagine a deployment which may be entirely atomic, or may contain several subpackages, each of which is atomic, so that several independent packages can be included and if one fails it can be retried (perhaps even automatically, some number of times?) or an alert can be sent to the administrator. Assuming that the integrity of the deployment itself is solid, "undo" operations can be defined for every possible type of supported change, and the order of operations can be guaranteed, then it follows that a deployment should be able to be rolled back automatically.

Further considerations:

1. All data should be serializable.
2. Ensuring the integrity of the undo operations is an absolute necessity.
3. Rollback failure is always a possibility, and this means corruption, so a full backup is recommended for all deployments.
4. There should be a complete record of all changes, packaged up in a manner easily identifiable as a deployed package (perhaps even as basic as a tar of all the SQL statements executed and files transferred).
5. It would be great to include some automated testing as pre-conditions or post-conditions of a deployment (i.e. a "smoke test")

Thanks for all the work you have put into this so far, I am very excited to see the results. I am not holding my breath for the Autopilot project, and this project has a corner on the best approach to this problem. I am not an experienced Drupal developer or PHP but I have 12 years of experience with Java and configuration/build/release management, and would love to be a part of this project. Please let me know how I can help!