A common set of Fabric tasks to reduce duplication of code between projects. For simple projects, you should only need to import these tasks and define your site-specific variables. More complex projects can wrap these tasks and their own in a local deploy() method.

1. Clone this yellfabric project.

    git clone git@github.com:YellLabs/yellfabric.git
   

2. Create a new virtualenv. Preferably with python2.6

    virtualenv -p python2.6 ~/venvs/fabric
   

3. Activate the virtualenv.

    source ~/venvs/fabric/bin/activate
   

4. Install the project requirements.

    pip install -r yellfabric/requirements.txt
   

5. Symlink yellfabric into your virtualenv's site-packages

    ln -s ~/projects/yellfabric ~/venvs/fabric/lib/python2.6/site-packages/
   

6. Configure your SSH details in ~/.fabricrc

• If using Fabric <1.4 set a username and private key path.

       user = USERNAME
       key_file = ~/.ssh/id_rsa
  

• If using Fabric >= 1.4 you can use your existing ssh_config.

       use_ssh_config = true
  

• env.custom_config_files: A list of dictionaries detailing additional config templates to be rendered and copied.

    env.custom_config_files = [
        { "source": "conf/foo.conf.template", "dest": "conf/foo.conf" },
        { "source": "conf/bar.conf.template", "dest": "conf/bar.conf" }
    ]
  

• env.template_key: Templating format to use. When set to $ it will use string.Template to do key/value substitution. When omitted it will fall back to the previous behaviour of %()s Python string interpolation.

    env.template_key = '$'
  

• env.non_template_exts: An array of file extensions that will not be parsed for template placeholders. Files with these extensions will be copied as-is. Currently only supported by yellfabric.java.

    env.non_template_exts = ['.pem', '.crt', '.key']
  

I was originally hoping to avoid global env variables and have each method accept and return it's own variables. However doing so would mean that they wouldn't be easily callable as standalone Fabric tasks, unless you specified all arguments by hand (like absolute paths) or wrap them in one-to-one classes, which kind of defeats the point of removing duplication. Instead I have attempted to make it clear what global variables each method uses and restrict utility methods for modifying them.

1. Add some form of version checking between this common project and the individual projects that utilise it, to enforce feature compatibility.
2. Use env globals less. If at all possible. I dislike this assumed magic.
3. Move individual project variables like hostnames out to .ini files. We shouldn't have to re-tag the project when we add more frontend nodes.
4. Tidy up tempdir after Java deployments.
5. Abort if rsync skips any source files.
6. Possibly the same for increasing log verbosity in Java deployments.
7. Check presence of WSGI file before touching. Will catch naming issues.
8. Change pip(1) log location.