Prototype based theming

or

lets avoid Drupalism where it is useless

Prototypes: A Better Approach to Development by Yuriy Gerasimov

DEV

CSS

Current problems

• Themers have to know Drupal theme engine
• Themers have to know PHP better then necessary
• Themers are waiting for Devs to get something to style
• "Hei, dude, add span wrapper here", "Hei, themer, I've added the button and it is not styled, could you?", "Form's markup is ugly I can't style it. - Meh, it is pain in the ass, may be some js+crunches? ;)"
• We have to use Drupal as CMF instead of CMS - so fuck the default markup, classes and HTML mess.
• Drupal 8 is comming...

DEV

CSS

Solutions

• Initially and outside of Drupal themers use HTML,CSS,JS and that's all. Because it is faster, nicer, cleaner.
• A bit less time for themers and a bit more time for devs.
• Through attempts and experiments we will create flow when themers will be able to use PHP templates, when everything will be available as variables without markup. (in future)
•  

Challenges

• Devs have to know Theme Engine, Render Engine, Form builder much better then now and then nothing will be pain in the ass.
• Themers have to generate lots of HTML, but we have Emmet and tons of prototyping tools.
• There are several ways to implement prototype on particular drupal piece and we will have to chose best one through experiments.
• Find nice Prototype generator tool for front-end

DEV

CSS

Benefits

• Cleaner and nicer HTML, CSS
• Faster themers work
• Deeper devs' knowledge
• Parallel development from start
• Less useless communication between devs and themers (during work)

DEV

CSS

Automated tests

DEV

QA

Manual QA is unimprovable and unreusable approach

• You could not speed up the process at all because it is almost impossible to automate it.
• You can't reuse anything from your experience or someone's experience
• It is something like directories tree with tons of pure html pages which are uploaded via FTP - awesome when you have 3 pages and hell when you have at least tiny CMS

***Here we are talking about bussiness logic and not about design.***

DEV

QA

Common workflow with manual testing

Dev made task on local env

DEV

QA

Deployed code to dev/stage server

QA tested and (did not) found a bug

Deployed code to prod/pre-prod server

QA tested and (did not) found a bug

Common amount of QA time

DEV

QA

• Test that site is available on stage domain - 1m (~10 min with getting url and logging to Jira). Each new piece of code potentially could put site down, so every time at least 1m.
• Complex test of commerce checkout at least with one product type and one payment - 2-5h. Then dev added new type of VAT - again 2-5h. Then we updated one of commerce submodules - 2-5h. And I don't think QA is able to fill full acceptance matrix and reclick it each time.
• You have huge site with 200+ contrib modules and it is time to make updates - 10-20 modules have minor or major updates. Is QA able to estimate and test the site?

Common manual QA experience and knowledge sharing

DEV

QA

Solutions

• Behat & Mink
• Test cases, user stories, part of tech spec written on Gherkin language
• Simple but still cross-browser, cross-device, multilingual tests
• Dev, QA write tests (Behat & Mink); PM, client (dream but still possible) read and modify tests (Behat);

DEV

QA

Challenges

• QA has to understand PHP and Mink at least on beginner level
• We need infrastructure to run tests 
• We will need MUCH more time to start cover everything with tests
• Devs will have to spend time on tests as well

DEV

QA

Benefits

• Instead of 5h to test checkout each time, spend 20h once and then sometimes 2h to modify.
• QA won't have to retest old and done stuff because it will be tested automatically on dev machines and during the builds.
• Ability to share knowledge between teams, departments.
• Actual fact of site stability: easy to give the site to SLA team for example.
• Forget about "Regression"
• After sometime QA will spend less time then now.

DEV

QA

Everything in code

Otherwise you are not a dev but manual site builder

DEV

Features for everything

Current problems

• Not everything in features
• Not all features in default state
• Bad structure of features
• No easy way to store some dynamic variables there

Benefits

You have to now all benefits ;)

Challenges

• Find clever way of storing configs in features/settings.php
• Different features for dev/stage/prod
• Start to use component's lock

DEV

Builds

Current problems

• We depends on prod DB
• Each valid commit should provide workable site instance
• Bad structure of features

Benefits

You have to now all benefits ;)

Challenges

• Move everything to features
• Build scripts
• SSD

DEV

Upgrade path

Current problems

• Deploy between environments is slow
• Deploy of updates is untestable with tests
• Each new checkbox anywhere is part of application so has to be inside code

Benefits

drush updb -y && drush rr -y && drush cc all

and any kind of functional will work on any env

Challenges

• Learn bunch of new functions
• Sometime you will generate content via code
• Repo conflicts in hook_install_n() functions

DEV

Sniffers

Automate code review

DEV

QA

CSS

Current problems

• No everybody uses standards
• We don't run sniffers for css, scss, advanced js
• It is pretty hard to integrate new sniffers or checkers
• TL spends some time to review problems which has not be pushed to repo even
• Sometimes code just looks differ for you

DEV

QA

CSS

Callenges

• Run it automatically on local envs
• Use same configs and flows everywhere
• Fix all custom code on all projects

DEV

QA

CSS

Infrostructure

Automate all previous automations

DEV

QA

CSS

Count how many time do you spend on non-coding stuff

DEV

QA

CSS

Common tasks which have to be automated

• Run sniffers. All sniffers
• Build site
  • Install profile
  • Use DB from live/stage
  • Upgrade path
• Configure environment
  • AMP
  • Solr
  • Assets
• Run tests. All tests
• Collect results and notify everybody

DEV

QA

CSS

CIBOX

DEV

QA

CSS

@podarok

@M1r1k

@ygerasimov

@Sanchiz

CIBOX

CSS

I will place nice diagram here some day

DEV

QA

CIBOX

CSS

Main points:

• One project - one CIBOX instance - one server
• Same env config for vagrant and cibox
• Pluggable sniffers, tests
• Predefined Drupal repo structure
• Integration with github/gitlab(not full one)
• Different types of notifications
• One PR - one site build
• !!!Speed!!!

DEV

QA

CIBOX DEMO

CSS

Text

DEV

QA