Drupal/BeanStalk Post Deployment tools – Josh Beauregard, DevOps – www.Knectar.com

View Github Repository Open presentation in a new window

sanguis

See all presentation from sanguis

Drupal/BeanStalk Post Deployment tools – Josh Beauregard, DevOps – www.Knectar.com

1 1

drupal-post-deploy-script-presentation

a presentation I about https://github.com/sanguis/drupal-beanstalk-post-deployment-scripts

On Github sanguis / drupal-post-deploy-script-presentation

Drupal/BeanStalk Post Deployment tools

Josh Beauregard, DevOps

www.Knectar.com

Drupal DevOps Meetup, Feb 13 2014

About me

  • DevOps at Knectar
  • d.o user: Sanguis
  • IRC: sanguisdex
  • Twitter: @sanguisdev
  • Github: Sanguis
has fragments
  • Been Developing Drupal sites since version 4.6 (2006-7 ish)
  • Moved in to a more DevOps like role 2011

And Never looked back

Disclaimer:

I do not work for beanstalk

I am not trying to sell beanstalk

It's just a tool that I found works for me

I believe that this algorithm could be used beyond

The Take Away

It is easy to contribute

Public repo space is free

Nothing is to small

It is easy co contribute.

Public repospace is free. Weather it is a module on d.o oir a a script on github or a whitepaper or blog post. even a tweet with a a problem solved can add to the global knowlegwe

Nothing is to small. the script that we are talking about has abiut 40 lines, includeing white space

The Challenge

Deploying changes in a minimally invasive way to the end user. No down time, reduce slowness taking up minimal amount of processing power.

Specs

No Touching

Throw out the napkin!

IF you have never heard this term it is version control based on notes scribbled down on a napkin about steps to reporduce the same results on live. Its a shameful practce that ever one trys every not and then.

Features

  • Fully reverted on production
  • Complete yet to the point from views and node field changes, and even in extream cases of adding a node features can be leveraged to deploy most changes.

hook_update_N()

For changes that dont fit anywhere else.

I commonly use this to enable the new feature that I just created. or what ever other new modules I use

Mkay

The Journey

when we first starting running a post deployment script it look something like this.

Version 1

                      drush updb -y
drush fra -y
drush cc all
As I mentioned this can be quite taxing if you have 3-4 developers constantly pushing and running these commands over and over. Generally we keep integration instance on a relative crowded 512MB cloud machine. (its a become some what of an interesting challenge to see how may drupal instances I can fit on them) eventually the Dev's look like this.

image source http://churchjobs.tv/

and the PM's were looking at me like this:

make it stop

why why why

image source: http://www.agirlonthedoorstep.com/

ever time they went to test a ticket the were getting 500 errors because of the overload on the server.

Why run this every time even where the was a small css or js change

$

I took stock of my tools

Tools at my disposal

  • GIT
  • Beanstalk deployment script window per server
  • Drush
  • BASH
  • roles/servers
  • We base out branching work flow on git-flow
  • Beanstalk provides several variables that the script can use $comment - that last commit message $date $author $commit-id

Why BASH?

ruby/Drush plug-in etc is better bash is everywhere if I have cl the odds I have bash. a small portable shell script is easier to update than a bash plug-in

Setup

      curl https://raw.github.com/sanguis/drupal-beanstalk-post-deployment-scripts/master/development.sh > /tmp/%USER_NAME%-%REVISION%.sh
bash /tmp/%USER_NAME%-%REVISION%.sh "%COMMENT%" %REVISION% %USER_NAME%
Set it up to download every time new changes to the script are immediately available to the old server role. Last week I added the -dbdump- option and used it on a server I setup 2 months ago.

Usage

Commit with a flag

  • -dbdump-
  • -updb-
  • -fra-
  • -bigups-
  • -cc_all-
  • -cc_cssjs-
  • -cc_block-
                      -dbdump-
drush sql-dump > /tmp/$DATE-bs-dump.sql
-updb-
drush -y updb
-fra-
drush -y fra
-bigups-
drush -y updb
drush -y fra
drush cc all
-cc_all-
drush cc all
-cc_cssjs-
drush cc css-js
-cc_block-
drush cc block

"git commit -am "Just upgraded drupal 7.26. -updb-"

Move On to your next task!

beanstalk will be triggering the script

it will email you if anything has gone wrong

How has this helped?

In sprints the dev can just dev and they don't have to think about getting changes ready for a PM, just commit, resolve the ticket and move on.

I no longer resolve a ticket (with a commit message) and before I can get to the server to clear the cache etc) the PM un resolves it.

PM's are being trained to look to see of the changes have finished deploying before kicking the ticket back to me. Other Dev's in the sprint can now view the log after pulling for actions needed to get their db settings up to date and just run them.

The time between deployment of changed files and updates to schema related to the updates have been greatly reduced, meaning schema changes that introducer breaks in to the front end actions.

Contact me