Drupal Continuous Integration Workflow
Download as PPTX, PDF5 likes2,026 views
This document outlines a Drupal development workflow using continuous integration practices. It describes the technologies used such as GitHub, Jenkins, code sniffers and Vagrant. Development rules are established including requiring code reviews before merging to master and not allowing a PR creator to merge their own code. Team roles like architect, developer and project manager are defined. The workflow involves reinstalling from scratch for each build and using update paths for staging environments. Challenges with the workflow like CI server downtime and slow builds for large projects are also discussed.
Drupal Continuous Integration Workflow
- 1. Drupal CI/development workflow by ProPeople born in Ukraine... ...or how to make developers hate you
- 2. Plan: - technologies overview - development rules - team roles - development phases - full workflow - demo - bottlenecks
- 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. ● reinstall.sh, runsniffers.sh, pull_stage.sh 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. Team rules
- 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. 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. Rule #3 (optional) bugs should be fixed by reviewer ● Review means responsibility ● Team has >=2 members that know how it works
- 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. Team roles
- 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. 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. Roles, Developer ● implement tickets according to specifications ● code review of other developer’s work
- 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. Full workflow
- 15. demo
- 17. New developers/freelancers should learn the rules
- 18. DevOps must be team member
- 19. Code review get hurt
- 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. Thank You Questions? Andriy Podanenko, http://dgo.to/@podarok Software Architect, DevOps Druler / ProPeople