Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Drupal Continuous Integration Workflow


Published on

Development workflow from the business point of view

Published in: Technology

Drupal Continuous Integration Workflow

  1. 1. Drupal CI/development workflow by ProPeople born in Ukraine... ...or how to make developers hate you
  2. 2. Plan: - technologies overview - development rules - team roles - development phases - full workflow - demo - bottlenecks
  3. 3. Technologies, techniks (DevOps) ● github, every developer has it’s own fork of master repo ● jenkins (github Pull Request builder plugin) ● code sniffers stack (PHP CodeSniffer, JSHint, SCSS-lint, twig-lint) ● every PR has it’s own unique drupal site built from scratch ● drupal profile/update_path driven development (drush si profile_name ... for every PR/stage build) ● manual code review, functional review before merging to master branch ● vagrant box and drupal codebase in one repo. ●,, scripts in drupal subdirectory in repo, executed at CI server every build. Can be used locally. ● github cibox repo for ansible scripts for ability to install whole infrastructure in ~15 minutes.
  4. 4. Team rules
  5. 5. Rule #1 master branch is stable ● No code in master branch without tests/sniffers/review ● Master branch is more stable than stage/production
  6. 6. Rule #2 PR creator denied from merging own code ● Code has to be reviewed by other team member before merging ● merge without review means breaking builds
  7. 7. Rule #3 (optional) bugs should be fixed by reviewer ● Review means responsibility ● Team has >=2 members that know how it works
  8. 8. Rule #4 There should be 2 siblings at every project for every role ● 2 architects/devops (architech + team lead) ● 2 frontend developers (senior + middle/junior) ● 2 devs (senior + junior, middle + middle) ● 1 pm
  9. 9. Team roles
  10. 10. Roles, Architect ● discuss technical solutions with client, gathering specs ● create project architecture (how things should be implemented) ● create tickets, split to subtickets (help from PM) ● estimate tickets ● code review, code quality assurance ● not much coding at all, some research, more management position than coding
  11. 11. Roles, PM ● demos to client, gather specs, bug reports ● make sure all tasks are defined as tickets ● review functionality implementation from clients perspective ● control priorities of execution of tickets ● resources and budget planning
  12. 12. Roles, Developer ● implement tickets according to specifications ● code review of other developer’s work
  13. 13. Development phases 1 - Reinstall from scratch every build reinstall script 2 - Update path, content can be edited at staging pull_stage script 3 - SLA(production) update path testing on staging
  14. 14. Full workflow
  15. 15. demo
  16. 16. CI workflow bottlenecks
  17. 17. New developers/freelancers should learn the rules
  18. 18. DevOps must be team member
  19. 19. Code review get hurt
  20. 20. CI workflow bottlenecks CI server down - commits stuck. Builds become slow on large projects. Decent desktops for dev team(SSD, lot of RAM) Overall process looks/feels slow Non responsible team member can brake a lot Team should consist from siblings Minimal task ~ 1 hour
  21. 21. Thank You Questions? Andriy Podanenko, Software Architect, DevOps Druler / ProPeople