Managing Plone Projects with Perl and Subversion

759 views

Published on

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.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
759
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Managing Plone Projects with Perl and Subversion

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

×