OxDUG speaker panel

	A	B	C	D	E	G
1		Agile Collective: Finn Lewis	Torchbox: Johan Gant	White October: Stephen Thomas	Other options	Glossary

2	Size & other details	Dedicated Drupal shop Drupal for 3+ years, but has longstanding Drupalers	30ish people - based in Charlbury - 4 - 8 people on Drupal 10 years, began with custom CMS. Drupal for 8 years	Multiple technologies. 30ish people but not all Drupal Drupal for 1+ years, taking over from a custom CMS		QA - quality assurance
3	Deployment workflow	Code: Local > Git > Dev/Stage/Production Dev is for deployment trial run; ideally, no changes here Database: Production > Stage/Dev/Local Code changes happen locally	Don't deploy on a Friday Have combined Dev/Stage server Bottleneck features in flight and reduce size of each feature Deployment users on remote servers	Local > QA/UAT > Staging > Live PR based workflow Staging is a mirror of production Hotfixes for urgent things		UAT - user acceptance test(ing)
4	Database changes	Features: sync database, make changes, then export into code; update code on dev etc, then revert features	Do use Features if it exports easily - otherwise use manual deployment steps. No great solution even now.	Tried Features; started from bad place Script as much as possible, use deployment steps		PR - pull request
5	Approval workflow	Uses Open Atrium Staging site for client acceptance testing (not content staging) - could disappear at any point	Codebase Each feature has a specification Each specification has a "what done looks like" section, a set of steps to be demoed Devs talk to clients; emphasis on transparency Process and documentation - great for onboarding	Uses JIRA - checkboxes for signofff QA environment At PR, another dev reviews, only then merges		JIRA, Open Atrium, Codebase - ticketing systems
6	Provisioning	Vagrant baseline Puppet historically, looking into Ansible	Vagrant as a baseline for developers Sysadmins automating build of staging etc. w/puppet Puppet is driving force Use Docker / Dokku on Django projects: learning curve	Ansible	VLAD - Vagrant, LAMP, Ansible, Drupal Containers e.g. Docker, Dokku platform.sh and plan for d.o to run tests on Docker	Puppet, Chef, Ansible - languages to describe provisioning configuration
7	Testing	Jenkins for one-click automated building Automate building and then run Behat tests Automated deployment? Well, that depends on the client!	"What done looks like" specification Selenium tests Wraith (see Johan's Drupalcamp London talk) Spot patterns and automate those	Begun automated testing but still early days Biggest challenge with CI is time: focus on biggest manual tasks and automate them	Code Enigma offer CI as a product: they invested up front and then sell it
8	Versioning summary	Git on self-hosted Gitlab Git flow	Self-hosted gitolite, but now uses Codebase's git Used to use Git flow; now it's without the develop	Feature branches; pull requests Learnt from Github flow	Feature toggles Workbench / workflow for forcing content versioning UUID for featurizing content Deploy module Node export/import
9	Backup strategy	Ongoing sites you're maintaining; vs gone-live sites Most clients have support/maintenance Puppet Server in Sheffield, takes 50 days of backups	"Give it to the sysadmins" Many clients manage their own Otherwise: nightly cronjob; files get snapshotted Bytemark	Push towards managed hosting Rackspace do nightly backup of everything	Should test backups occasionally, as you can get silent data corruption - filesystem underneath backups corrupts rsync over ssh can corrupt CI can prevent this
10	Security notification	Monitoring Patch Wednesday Subscribe to mailing list of announcements Twitter & IRC: @drupalsecurity Timing is always going to be an issue for someone in world Jenkins could patch every Wednesday?	Connections to security team, through volunteering to help Also Twitter, IRC, mailing list etc.	Main client got hacked BEFORE moving to Drupal, so expectations! Drupal monitoring not sophisticated: stream of data from site Following the right people on Twitter quickest way Have automated vulnerability scanning in place in case accidentally turning something off	Multisite - if you break one you break them all Maybe have more process to protect a multisite Acquia update by hot-swapping old env for an updated env
11	Updates processes		Maintenance clients have a monthly audit, human assessment, write a report, discuss with client, deploy for testing No explicit clause for updating without notice; exception was Drupalgeddon	Has out-of-hours contract; rotating pager duty! Critical fixed out of hours; minor talk about next day Say to clients "it's a risk for us if you don't do this" Don't have to ask permission if judgment says do it
12	Project management		Documented processes, otherwise they're habits	Transparency of process
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100