Values and Principles
=====================

Single-command deployment
    A deployment should *always* only consist of running a single, simple command.

Repeatability, reliability
    If a deployment worked yesterday then it should also work today. And it
    should result in the same setup.

Expressiveness, readability
    Make service definitions readable: avoid having large blocks of mechanical
    code that does not communicate its intention.

Reusability
    When finding a good way to solve a specific deployment problem (like
    managing files, services, secrets, ...) we want to make the solution
    re-usable so that we can benefit from it whenever we meet the same problem
    again.

    An important point to reusability is to make re-use simple enough that you
    do not have to prefer short-cuts over doing it right.

Resistance to entropy, automatic repairs
    The target machine will likely accumulate entropy over time. Do not expect
    a perfect environment but make reasonable adjustments to achieve the
    deployment goal.

Platform-independence
    A service description should use a very broad model where the mechanics of
    the model do not depend on the specifics of any single platform: be it
    Unix, Windows or anything else.

    In our case the component model is completely agnostic to any platform.
    Only specific component implementations become tied to a platform, e.g. the
    Symlink component being specific to POSIX platforms.

    Also, make it possible to make platform-specific parts of the model
    explicit. Allow specifying multiple platform targets for a single service.

    We do rely on Python being available, though.

Simplicity
    Complex service deployments are bad enough as they are – we do not want to
    make them any more complicated. We especially do not want to break
    expectations about existing components; people who are experienced
    with them ought to be able to predict their behaviour.

    Similarly, we do not want to invent a whole new programming language and
    thus selected Python both as our choice for implementing batou and for
    implementing specific deployments.

    You can do whatever Python can do in your code, we won't handcuff you.
    Conversely, we will indicate areas where you need to respect certain
    assumptions (like the ``configure()`` method) as we can't effectively stop
    you from shooting yourself in the foot - and we won't pretend that we
    could.

Domain-agnostic
    Batou should not make any assumption about your service: we do mostly
    deploy web application stacks but honestly, the abstract model does not
    have to and should not know about that. The same is true of any other
    aspect of your service: it should be possible to deploy any software that
    you, as an administrator, can install on a system.

No additional components
    No additional active components in your service environment are required at
    runtime or needed in your application. See also: "Domain-agnostic".

Automatic dependencies
    Dependencies between separate components shall be determined automatically.

Continuity
    The same service model and tools should be useable for initial and
    incremental deployments.

Minimal downtimes
    Avoid unnecessarily taking components down. Ideally we can run deployments "in-flight".

    Also, deployments should be fast. They should be especially fast if
    nothing needs to be changed.
