Notes about migrations... could be used to start a project (Chrysalis?). Are there some projects that already do that?

README

#########
Chrysalis
#########

Chrysalis (may be renamed to "slough") is a general purpose migration
framework, written in Python. 
It focuses on automating actions you perform to upgrade a product.

.. warning::

   This project is experimental. At this stage, it just describes concepts.
   Perhaps the concepts are implemented by some existing tools.

A typical migration for a web service could be:

* ask admin for confirmation
* enable maintenance page
* stop frontends
* backup data
* update configuration
* provision machines (upgrade software)
* migrate databases
* restart frontends
* run smoketests
* disable maintenance page.


***********************
Upgrades are migrations
***********************

Provisioning is not enough to manage upgrades.
Database migrations are just a part of the upgrade procedure.
We need migration scripts and workflows.


*****************
Migration scripts
*****************

* Recipes are libraries that provide classes with forward() and backward()
  methods.
* Dispatchers manage lists of actions to run and watch/notify stop conditions.
* Migration scripts load, configure and run recipes.
* Collecter grabs the list of unapplied migration scripts.


*******************
Migration workflows
*******************

Automating everything is hard, sometimes impossible, sometimes unwanted.
A migration procedure is a workflow: it passes from one state to another via
transitions. Most transitions can be automated, but some may require human
interaction.

Example of human interactions:

* setup SSH keys
* update configuration where defaults are not suitable
* review and confirm some actions
* perform actions that have not been automated yet


********************************
Iterative deployment development
********************************

When you start a project, you do not want to spend days to get the perfect
deployment workflow. In fact, you usually cannot even get a suitable deployment
workflow at first. Partly because you do not know how to deploy things you
have not developed yet. Partly because you want to focus on proof of concepts,
where automated deployment is not top priority.

Chrysalis allows you to setup interactive workflows, where you can tell the
user to perform actions you have not automated yet.


********************************
Remote-control multiple machines
********************************

On distributed architectures, you have to orchestrate migrations on multiple
machines. Chrysalis runs high-level migration scripts that use your favorite
remote-control tools, such as fabric or salt.


****************
From DEV to PROD
****************

Migrations are part of the development process. Several developers can
contribute to migrations, concurrently. Chrysalis is made to reproduce
migrations over every environments, from DEV to PROD.
The differences between DEV (tends to be monolithic) and PROD (tends to be
distributed) are managed via configuration. Chrysalis supposes you manage
architecture as configuration.

chrysalis status [SCRIPTNAME] tells whether SCRIPTNAME has been successfully applied or not (optionally provides details). By default, echoes global status (version ? list of all applied scripts ?).
chrysalis forward [VERSION] applies forward scripts to go to VERSION (newest version is the default).
chrysalis backward [VERSION] applies backward scripts to go to VERSION (default is one step backward).

Migration scripts can be any executable (bash, ruby, python...), provided they implement "status", "forward" and "backward" ("forward" is the only mandatory).

Base classes or templates could be provided to easily implement Python scripts.