• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Managing Plone Projects with Perl and Subversion
 

Managing Plone Projects with Perl and Subversion

on

  • 1,050 views

How an in-house solution developed in Perl helped our Plone developers to streamline their work....

How an in-house solution developed in Perl helped our Plone developers to streamline their work.

From the use of Subversion (and Trac) to keep track of development, sharing code, and bundling packages, to the creation of a program for managing dependencies, building the system, creating release RPMs and tracking deployments.

A test case by Eurotux Informática.

Statistics

Views

Total Views
1,050
Views on SlideShare
1,050
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Managing Plone Projects with Perl and Subversion Managing Plone Projects with Perl and Subversion Presentation Transcript

    • Managing Plone Projects with Perl and Subversion Luciano Rocha yapc::eu::2009
    • History
      • 2004: members of Gil (Linux Research Group, in Universidade do Minho, Portugal) develop the group's site in Plone
        • Plone 2.0
        • Zope 2.7
        • Python 2.3
      • 2005: members asked to join Eurotux Informática as a Web development team specialized in Plone
    • What's needed?
      • Python
        • A scripting language
      • Zope
        • An application server written in Python with security extensions in C
      • Plone
        • A collection of Zope Products, making a CMS
    • Zope site layout
      • Extensions/
      • Products/
      • bin/: management scripts
      • etc/: configuration files
      • import/
      • inituser: admin user and password
      • lib/python: extra python modules
      • log/: access and error logs
      • var/: objects database
    • Caveats
      • Zope C security extensions for python are very dependent on python release:
        • Always a version or two behind
        • Solution: compile and install the required python
          • Problem: what about dependencies and needed modules?
          • How to automate their installation?
      • Keeping track of upstream source
      • Keeping track of our source
    • Evolution In 2005: a single Makefile
        • Unwieldy
        • spaghetti rules
        • not really appropriate for our needs
        • make start|stop|build|up
        • A python, zope and system modules compiled for each site
    • Evolution
        In 2005/12/28:
      • First commit of a Perl version
      • Wanted: start|stop|build|create|restart|list|debug|run|autodeps
      • Just the skelleton
      • Share python and zope installations as possible
    • Initial Architecture
      • Shell script generating textual description of policies, dependencies and requirements
      • Perl script for generating RPMs
      • Shell scripts for compiling
      • Perl script
      for building and mgmt builddeps.sh Server Client Client RPMs SVN HTTP build.pl browser
    • Initial Repository Format
      • System packages:
        • /system/<name>/
          • trunk/
            • .buildsys/
            • .buildsys.local
          • vendor/
          • tags/
          • branches/
    • Initial Repository Format
      • Zope Products
        • products/<name>/
          • trunk/
          • vendor/
          • tags/
          • branches/
      • Site types:
        • projects/sites/<type>/support/
          • dependencies_system.txt
          • dependencies_plone.txt
          • policy.txt
    • Problems
      • Not real time
      • Not all perl
      • “requires” and “provides” for Products and sites cumbersome to maintain
      • New Plone release implies many Products' vendor/ update
      • Ad-hoc creation of RPMs
    • Simplification
      • Keep dependencies_system.txt, get rid of all else
      • Introduce bundles/<bundle>, with pointers to Products
      • Split single script into modules
      • Direct access to repository: SVN::Core
      • Introduce Releases:
        • List bundles and their externals;
        • Ignore duplicated Products
        • Create releases/<name> with externals only
    • Re-Simplification
      • Introduce sub-bundles:
        • One for Plone; one for site; one for ...
      • Re-engineering Release:
        • Create release/<name>/bundles/
        • Walk bundles and subbundles; follow externals
        • Copy files; create externals for directories
    • Introduce Deployments Deployment:
      • Associate releases with servers
      • Easy update to new release
      • Easy RPM generation
      How:
      • Maintain /deployments.yaml in repository
    •  
    • Community Evolution
      • Products are passé , create standard python modules instead
        • New bundles/lib/python
      • Distributing and relying on Eggs
      • Adopted buildout
      • Is there a future?
        • Users are python developers
        • As little deviation from community as possible
    • Statistics
      • 279 commits:
      • 54 files
      • 12726 lines
      262 lmf 13 rsa 3 lmb 1 lms 279 total