Andreas Jung was one of the first speakers at the DZUG Tagung 2008 talking about buildout and some advanced topics. I assume here that everybody know what buildout is so I skip the introductionary explanations.
Points he is making is: buildout is agnostic regarding the area of use. You can use lots of things, eggs, svn/cvs, downloads etc.
Buildout in a software lifecycle
- Developer works in development sandbox with a development.cfg
- There is a staging environment with staging.cfg
- There is a life environment with deployment.cfg
Those three configuration files can have parts in common but usually they will have differences.
Problems at Haufe Mediengruppe
At Haufe Mediengruppe they have/had the following issues:
- minimum of 3 big Zope project clusters
- together about 100 Zope products, 100 python modules
- different sandbox scripts for every project cluster and environment (dev, test, prod)
- different requirements for every environment
The idea is to use buildout for this to automate things but using the usual tools was not enough for this environment. Thus haufeskel Templates was born.
haufeskel Templates
It consists of
- module specific configuration: modules.cfg
- Host/environment specific configuration: <host>.cfg
- buildout directory skeleton
- (there was some more here)
It’s based on paster and ZopeSkel.
You have as in ZopeSkel some template variables. These configuration will be transferred to the module configuration. This will create the internal global configuration. This will be mixed with environment specific configurations. With this various configuration files for buildout can be created.
He then showed a little demo of how it works.
We saw various module configurations, such as modules for the development environment, modules for SAP and so on.
A module configuration is defined hierarchical. We saw a modules configuration which defined svn checkouts and for one configuration we saw a huge list of modules which are needed for an environment. This can be eggs, svn checkouts or download archives.
Module configurations can also include other configurations which are included. This way configurations can be extended. You can access variables from the other configuration file via e.g. ‚products0: $common.svn.products0‚.
The host configuration files define things like ports (zope, ZEO, etc.) , filesystem locations, IP addresses and so on.
With these module and host configuration they can then create an environment configuration. This is then done via paster with several templates.
There you have to answers some questions:
- Which environment (ro,xweb,zeo,test,dev). This will automatically include modules_<envname>.
- Different ports
- usernames/passwords
etc. There actually were quite a lot of questions.
What comes out is a directory structure with a generated buildout.cfg which is specific for the environment you have choosen in the paster questions.
(Disclaimer: Transcript without any guarantees of correctness)