DevOps leads the way to better Drupal development

For the last several years the Drupal community has had a conversation about the best way to set up version control on a Drupal site that has a proper development stack consisting of local, development, staging, and production environments.

One camp likes to track the entire site including core and contributed module files. Proponents like how this allows us to see changes to files across the entire site on each environment, while detractors suggest this is unnecessary and inefficient given that we're not planning to ever change the vast majority of the codebase in the site (Drupal core + contributed modules).

The other camp likes to utilize tools like Drush Make to build sites using .make files and then track only those files unique to this particular site, excluding both Drupal core and contributed modules. Proponents suggest this is a more efficient and honest architecture, whereas detractors lament the lack of control and potential DevOps headache this creates when it comes time to deploy the site from one environment to another.

This talk will demonstrate how we can have the best of both worlds by setting up a DevOps infrastructure that capitalizes on Git's versatility for both version control and DevOps, which will allow us to develop efficiently yet still maintain full control of the entire site codebase.

The demonstration will take advantage of Drupal's wonderful install profile concept and Drush Make to build sites and track only the unique code for the site in Git. It will then connect the dots by automating a build process that prepares the site for testing, deployment, and contribution from other developers.

Session Objectives

- Shine light on how DevOps can solve longstanding riddles with Drupal site version control
- Provide an explanation of Drush Make and how it can alter your development workflow to help you write more reusable code
- Make a case for why "Every site [can be] an Install Profile"
- Show how you can successfully integrate a build process into your development workflow
- Illustrate how to minimize your code footprint, automate all the things, and allow you to hone in and focus on only what's important to building your site

Transcript

1. #WHERE’S YOUR REPO? DevOps leads the way to better Drupal development experience level: Advanced time slot: Wednesday · 02:15-03:15 room: G - Trellon | 4th floor speaker: Kevin Champion
2. Kevin Champion developer independent contractor 4 years Drupal
3. #WHERESYOURREPO?
4. #WHERESYOURREPO?
5. #WHERESYOURREPO?
6. #WHERESYOURREPO?
7. DevOps is critical to development
8. DevOps is not separate from development
9. DevOps does not *just* help development
10. DevOps is not just *after* development
11. DevOps is not just deploying environment to environment
12. DevOps is farther down the stack
13. DevOps is critical to *HOW* you develop
14. #WHERE’S YOUR REPO? is important
15. Camp keep-it-simple
16. walkah.net/blog/every-drupal-site-install-profile/
17. Camp only-what-you-need
18. Install profile
19. Not in repo
20. Must run builds
21. Drush Make recurses
22. download make file develop your git flow upstream changes? Builds in development run build
23. Camp only-what-you-need Camp keep-it-simple vs. pragmatists purists
24. ~93% smaller codebase ~9,031 fewer files ~1,007,961 fewer lines of code What’s the difference?
25. Benefits of the purist everything in its right place reusable components
26. Architecture is important
27. Builds!? 7 levels of building hell additional steps extra time processor intensive inherently flaky hard to learn team dilemma devops headache
28. can we be pragmatic purists? practical architects?
29. Yes
30. download make file develop your git flow upstream changes? Confusing dev and devops run build
31. dev devops download make file run build develop your git flow serve build result in vhost
32. additional steps extra time processor intensive inherently flaky hard to learn team dilemma devops headache Separating dev and devops 7 levels of building hell
33. devops download make file deploy by pulling from builds repo commit build result to separate builds repo build triggered run build
34. dev develop your git flow upstream changes? pull latest build from builds repo
35. additional steps extra time processor intensive inherently flaky hard to learn team dilemma devops headache Setup alleviates build woes 7 levels of building hell
36. 1. Set up build server directory structure 2. Create builds repo, set remotes, first commit 3. Run first build 4. Commit first build to builds repo 5. Deploy first build 6. Automate build process Deep dive Set up builds server
37. #1 Build server directories
38. #2 Set up builds repo builds_repo build vhost
39. #3 Run first build
40. #4 Commit build to builds repo build
41. #5 Deploy first build vhost
42. devops download make file deploy by pulling from builds repo commit build result to separate builds repo build triggered run build
43. #6 Automate build process nightly? git hooks? github polling? Trigger continuous integration server? bash scripts? drush commands? Process
44. Drush git_ops github.com/kevinchampion/drush_gitops gitops_init: set up build server directory structure gitops_build: run build, commit result, deploy build server gitops_clone: clones builds repo, sets up working repos gitops_pull: pulls latest build, replaces working repos working environment
45. DEMO
46. DevOps is critical to *HOW* you develop
47. #WHERE’S YOUR REPO? becomes... # Where are all of your repos because you set up a DevOps flow before you even got started developing and thus efficiently make use of reusable components without having to sacrifice on your ability to deploy your sites from one environment to another ?
48. kevin.champion@gmail.com @kevinchampion drupal.org/u/kevinchampion github.com/kevinchampion/drush_gitops I’m available for work Thank you EVALUATE THIS SESSION: AUSTIN2014.DRUPAL.ORG/SESSION/DEVOPS-LEADS-WAY-BETTER-DRUPAL-DEVELOPMENT