batou 0.1.5

A utility for automating multi-host, multi-environment software builds and deployments.

batou

Batou is a tool to deploy services consisting of interacting components for development and production environments.

Working with batou consists of two steps:

• defining services

• deploying services

Defining a service

Services are defined by describing the components they are made up of as Python code that will be run during a deployment and by specifying the environments in which the components will be deployed.

Batou gives you a structure for arranging your components and a library that makes it easy to write components.

Component definition

Components are pieces of software whose configuration depends on the environment and host their are configured on as well as the configuration of other components.

Here’s a component that touches a file:

class Touch(Component):
   @step(1)
   def touch(self):
      self.cmd('touch /tmp/asdf')

Environments

Environments provide configuration to components and select which components should be installed on which hosts.

Here’s an environment definition that would be suitable for development:

[hosts]
localhost = touch

Deploying a service

Locally

You can deploy any configuration locally that you want. In the most simple case you select your devel

Remotely

In-depth

The sizing of a component depends on two factors: coherence and distribution. If some software is always build together and/or shares a lot of build code, it should be a single component or depend on a shared component. If software needs to be run on different hosts independently it should be split in multiple components or make use “features” to control partial configurations with shared code.

Other topics

• deployment into service user

• code push/bouncing

• check in multiple development environments (per developer)

• run a production deployment locally for debugging

• use secrets management

• use templating (inline, files)

  • jinja

  • mako

• use base components

  • haproxy

  • buildout

• use hooks

• use features

• make stuff convergent

• host name normalization

• cross-environment protection

• component API

• config helpers

  • address objects

  • netloc objects

Developing batou

Author:

gocept <[e-mail]>

Online documentation:

http://docs.gocept.com/batou/

PyPI page:

http://pypi.python.org/pypi/batou/

Issue tracker:

https://projects.gocept.com/projects/batou/

Source code:

https://code.gocept.com/hg/public/batou/

Current change log:

https://code.gocept.com/hg/public/batou/raw-file/tip/CHANGES.txt

Change log for batou

0.1.5 (2013-04-24)

• Speed up deployments by improving the logic if bootstraps are required. Now bootstrap is left out if not required in most cases.

0.1.4 (2013-02-07)

• Always use a fixed locale of en_US.utf8 so that output from external commands remains predictable (RT 86245).

• (Re-)run bootstrap if buildout.cfg or any file in versions is newer than bin/buildout. This helps to keep buildout up-to-date.

0.1.3 (2012-10-15)

• Leave umask alone. If it must be set for service deployment, we’d better resort to .bashrc or similar.

• Improve EXEC_PREFIX detection code to work with both Python 2 and Python 3 target versions.

0.1.2 (2012-04-12)

• self.config_attr(‘attribute’, ‘list’) syntax for list-valued types in configuration files.

• Call setlocale at batou-local startup to initialize locale settings throughout component execution.

0.1.1 (2012-04-02)

• Add support for global find-links in Buildout. If a secret [buildout]find-links is found, it will be put in component.find_links.

0.1p2 (2012-04-02)

• Packaging fix: include test fixtures to enable running tests on installed eggs.

0.1p1 (2012-04-02)

• Correct packaging bugs: missing .txt files etc.

• Unify license to state ‘ZPL’ consistently in all places. We used to have a mix of ZPL/BSD license statements.

0.1 (2012-04-02)

initial release