Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.
For the best experience please use the latest Chrome, Safari or Firefox browser.
Encolpe DEGOUTE
- Open Source advocate from 1996 and president of ALDIL (Lyon Free Software User Group) since 3 years.
- I worked mainly on Nuxeo CPS and Plone and I contribute on many other projects on Free Culture (Brewery, Books, Translations, Trainings, Arduino, 3D Printers).
- Now I'm at Bearstech for Plone, Django and some Hackable Device stuff.
zc.buildout
- It helps you to have a Plone installation that you can repeat as many times as needed on a project.
- It's hard to build your configuration at a projects' beginning.
Zopeskel
- It helps you to write the zc.buildout configuration at the projects' beginning.
- But this setup is for you, not for your team and is not ready for production.
- You can unify practices for your team but not for customer teams.
- You want something easy to deploy in Jenkins. Yes, you want it!
Customer stories
Your Skel is driven by customer needs
- Ingeniweb
- Education group with one site by formation
- ENS de Lyon (UNIS service) with offical and projects sites
IngeniHosting
- All was managed by some Python scripts
- Always the same OS configuration
- Always the same Plone version for years
Education Group
One Virtual Machine for each site
- 70 sites 3 years later…
- Traffic can be very low on some sites
- Each time all applications are compiled and installed separately
Education Group
All is managed from zc.buildout
- A central buildout.cfg file
- A subfolder for base project and applications
- Another subfolder for project specific includes
Education Group
After 3 years we need to be more flexible
- Separate base configuration from addons configuration and applications
- Group cache settings and features on one single server
- Use share hosting for some sites
- Use scalable hosting for some sites
ENS de Lyon - UNIS
Shared hosting
- All VMs and servers are differents
- Always the last Debian Stable (without major release upgrade)
- We want to create only configuration files for external applications
- All sites don't have the same Plone version
- We must manage application installation and addons in it
ENS de Lyon - UNIS
After 2 years
- 50 deployed sites and configured in half a day
- Each plone sites reach its target with the good addons (and only them)
- Nobody there knows Plone and buildout in the deep
Then what are our use cases?
- We want to be able to switch applications in the same stack level
- Nginx/Apache configuration
- Squid/Varnish compilation and configuration
- Pound/HAProxy compilation and configuration
- Have profiles
- Manage KSG for addons
Zopeskel or templeet
See tomorrow conf on Templeet at 11h45
zopeskel.unis What do we use to make this generic?
- extends => Order is important
- += => Don't mix = and +=
- <= => It copy the content before the interpretation
- ${:_buildout_section_name_}
give you the current section's name
zopeskel.unis
- An almost empty buildout.cfg file in the skel
- Some subfolders to manage configuration (profiles, profiles/etc, profiles/modules)
- Some subfolders to manage development and production (templates, patchs, src, var)
zopeskel.unis profiles
- development.cfg
- standalone.cfg
- preproduction.cfg
- production.cfg
zopeskel.unis profiles/etc
- defines.cfg
- base.cfg
- project.cfg
- versions.cfg
zopeskel.unis profiles/modules
- cas.cfg
- ldap.cfg
- getpaid.cfg
- theming.cfg --> Diazo
- deco.cfg
- plonide.cfg
- metnav.cfg
What next?
- Take it as an example
- Structure refactoring
- Go on templeet
- Have a database for addons KSG