eZ Community » Blogs » Benjamin Choquet » On automation and contribution

By

Benjamin Choquet

On automation and contribution

Wednesday 21 January 2015 12:44:05 pm

  • Currently 5 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Last thursday I had the opportunity to speak at the eZ Meetup in Lyon where I showcased the tools and techniques we use at Heliopsis to speed up eZPublish 5 site development. 

First of all I'd like to thank the eZSystems crew and particularly Sylvain Guittard to make this happen. Thanks also to all attendees who resisted the urge to beat me up for not speaking loud and clear enough ;)

If you're interested, my slides are online (french language). For those of you who don't have the good taste of being french and don't understand what they are about, you can find a quick summary at the bottom of this post to get the gist of it. The slides include a few code examples so you might want to check them out anyway.

We're eager to get some feedback on the matter. What do you think of what we do? Do you use similar techniques? Other tools? What else do you think could be improved?

I concluded my speech on a (friendly) rant about how hard it sometimes felt to work on eZ5 due to its young age, the lack of public roadmap and of clear contribution policies. Once again, I hope the guys (and gals) at eZSystems didn't take it personally as I think they've done an amazing job at the product. I merely wanted to point out the difficulty of knowing where to stand from a community partner point of view and how frustrated we were not seeing the open source side of the project flourish like we'd like it to.

This subject could deserve a dedicated post but here are some interesting things I heard while chatting afterwards:

  • Pull requests are treated on a voluntary basis by eZ engineering
  • The unofficial rule is to wait for at least 3 +1s before considering merging
  • They feel a bit overwhelmed by the number of pull requests and encourage community members to check them out and +1 the ones they find legit
  • They also are eager to get feedback on their own pull requests before merging them, particularly regarding the forthcoming UIBundle
  • They already included non ezsystems bundle to their product and are willing to include any other interesting library that would suit their (our?) needs

We're curious to know how the community feels about this and what can be done to ease the process of building great tools around the new platform. More on that later but we would like to move forward on releasing our menu generation bundle and will need a bunch of goodwilling peers...

 

 

Slides summary:

  • We use a series of tools and techniques allowing us to initiate an new project in about 5mn* We achieved that by automating much of the repetitive tasks prior to project specific development and reusing what we can
  • Organising code: 
    • We copied ezpublish-community repo into a custom skeleton package including custom dependencies and configuration  
    • We host our private packages with a little help from Satis  
    • It enables us to leverage composer create-project command to quickly get a preconfigured ezpublish app with its dependencies
  • Using legacy only in the backend:  
    • Legacy custom code (settings and extension) is symlinked in the corresponding legacy folders to the global symfony app repository by a composer script  
    • The legacy Fallback Router is overriden to whitelist legacy routes  
    • Legacy errors are delegated to the symfony layer by means of ini configuration and a custom module throwing exceptions  
    • This cuts the need for a legacy pagelayout and allows us to (almost) completely bypass legacy in frontend
  • Preparing contents: 
    • We automate basic contents operation (db setup, content types definition, content tree creation, permissions definition) with symfony commands to reset or update database.   
    • This allows us to completely bypass the setup wizard and the legacy backend for content structure and administrative tasks. 
    • I also suggest to have a look at kreait/ezpublish-migrations-bundle which seems to do the same as our custom bundle but with a doctrine-like groove 
    • We created a bunch of helper migration classes to write less verbose code than with the plain public API  
    • We stick to set of basic content types from project to project  
    • We also use a common set of attributes accross those content types in order not to wonder which is which. This also enables template code reuse.  
    • Regarding permissions, we came up with a set of blueprint permission roles we reuse from project to project and customize through limitations
  • Reusing controllers and views:  
    • The main hazard we had to overcome was knowing the best way to render a given feature (content view, sub controller, twig extension, ...). We designed a flowchart to help us ask the right questions.  
    • We created a base design bundle to build upon 
    • It contains basic controllers (folder, files, redirects) and a default controller injecting layout related params in the content view (path, metadata, tracking tag, ...)  
    • We also created a detailed template hierarchy which we can reuse, with clear extension points  
    • We introduced a skinning mecanism by way of a global twig service to let our templates vary between siteaccesses  
    • Finally, we create dedicated bundles whenever possible. This is the case of our already open ezforms-bundle but also our upcoming ezmenu-bundle
Proudly Developed with from