Using Git to Manage Deployments: David Kinzer 

● General overview of deployment. ● Some Drupal specific considerations. ● Walk through 2 part demo of technique. ● Some summary statements. ● Answer questions (but feel free to interrupt). Introduction 

Some basic terms: Git - we all love this wonderful little tool. Commits - Are the way to save changes. Push/Pull - Is how we share commits. Deploy - In a second... Drupal - Is a PHP CMS/Framework for building web apps. 

Relax, it’s all good. 

Unless you don’t version control. 

DEPLOYMENT? 

There are so many steps… > LAMP stack. > Development... > Testing... > Deployment 

No content

No content

A deployment, of sorts. 

There are many ways to solve this... 

Here’s one way... > cd project > touch project.tgz && tar -czvf project.tgz . > scp project.tgz somehost.com:~/project.tgz > ssh somehost.com ‘tar xvf project.tgz -C www \ && rm project.tgz && chmod 755 -R www’ 

Makefile ---------------- deploy: bash bin/deploy.sh A little bit better might be... bin/deploy.sh ------------------ #!/bin/bash tar… scp … ssh ... 

> vagrant up 

> git pull origin master? … Sure this can move our files, but what about any Drupal specific consideration? But what about plain old git pull? 

What’s Drupal Specific Here... ● Any database changes… ● Enabling disabling modules… ● Configuration changes… ● Caches... 

No content

Drush to the rescue!!! ● drush updb ● drush cc all ● many other goodies... 

Makefile ---------------- deploy: bash bin/deploy.sh Another approach might be... bin/deploy.sh ------------------ #!/bin/bash cd project git pull… # plus some drush magic.. drush updb drush cc all 

The ultimate magic is invocation... > git push 

Git Supports Hooks. .git/hooks ├── applypatch-msg ├── commit-msg ├── post-update ├── pre-applypatch ├── pre-commit ├── prepare-commit-msg ├── pre-rebase └── update 

First way… > git clone --bare project > cd project.git/hooks/ > vi post-update > cd - > git clone project.git dev > cd dev && “make changes” > git push Prepare the repos... Second Way… > git clone live dev > cd project/.git/hooks > vi post-update… (caveat) > cd ../.. > git config \ receive.denycurrentbranch false > ... 

To Bare or not to Bare... NOT bare is better IMHO because you can version control repo preparation and deployment script with the project…. 

DEMO TIME In 2 parts 

We can invoke whatever power... Docker Vagrant Whatever 

So, what to choose? This decision is guided by need. 

No content

Any solution can benefit... > git push 

Remember, relax, it’s all good. David Kinzer Jenkins Law Library twitter/dtkinzer github/dkinzer 

Photos/Illustrations Credits... ● "Man Fig Miniature Wave Sit Rest Relax Friendly", by Anja Osenberg, CC0 1.0 ● "36100 Bangladesh Air Force MIG-29 Landing with the Drogue Parachute Deployed", by Fisal Akram, CC BY-SA 2.0 ● "Parachutist Skydiver Skydiving Sky Parachute", by Lynn Greyling, CC0 1.0 ● "Grow Blossom Time Lapse Sequence Amaryllis Flower", by Stefan Schweihofer, CC0 1.0 ● "Puzzle Cube Wood Block Toys Wooden Toys Build", by Hans Braxmeier, CC0 1.0 ● "Magic", by Bart Cayusa, CC BY-SA 2.0 ● "Simple Drupal Wallpaper", by Matt Farina, CC BY-SA 2.0 ● "Problem Shield Note Street Sign Road Sign Sky", by Gerd Altmann, CC0 1.0 ● "Drush Logo", by Dan Morrison, GPL V2 ● "An Illustration to the Markandeya Purana: The Gods invoke Devi Estimate", by Unknown, Public Domain ● "Livarna", by Viktorija Rozman, CC BY-SA 3.0 ● "Bare Feet Foot Tanned Brown Hair Water", by Public Domain Pictures, CC0 1.0 ● "Cattleman NM55 Revolver Sketch", by Don Stewart, CC BY-SA 2.0 ● "Control!", by Faramarz Hashemi, CC BY-SA 2.0 ● "Flight Controls", by Bryan Burke, CC BY-NC-ND 2.0 

Please fork my demo. 

I’ll git pull yours, if you git pull mine. 

This repo’s off the hook. 

More Credits... ● "Canon 550d - Snail on Fork", Doug Wheller (@Doug88888), CC BY-SA 2.0 ● "P as in pull", by Kristina Alexanderson (@cclones), CC BY-SA 2.0