Drupal 8 DevOps . Profile and SQL flows

Drupal 8 DevOps*.Profile and SQL flows.

*DevOps is Development Operations Engineer.

Takes care about how development process lives and whether it could be

improved continuously.

About a speakerAndrii Podanenko, FFW

Team Lead, Software Architect, DevOps

A bunch of contrib modules maintainer

D.org power up group mentor

UA Localization group manager.

http://dgo.to/@podarok

@podarok or @podarok_ua

Technologies, touched within current session● Drupal 8(7)

● CIBox (Jenkins, GitHub, Ansible, Virtual Machine)

● Drush, Drupal Console

● Vagrant, Virtualbox, linux containers (Docker style)

● LAMP (Linux, Apache, MySQL, PHP)

The crucial point for the development is a...

Speed of Delivery

If you able to deliver a project for a small amount of time...

you can become a winner in terms of marketing and sales

If you could demo particular feature any time...

you could give the customers thoughts they are controlling the process of developing the product

If you could deploy features/fixes more frequently...

you could let the customers think they can commit changes to their business easily through the product you are developing

If you could provide specific features for UAT* any time...

you could get decreased overall UAT time and saved tons of funds for pre launch testing

*UAT - User Acceptance Testing

If you could test every specific feature on a dedicated environment - feature build (ci build)...

your QA could be happy which would make a customer happy as well

*QA - Quality Assurance engineer

If devs are involved into creating initial user-guides...

delivery would be smoother and the client would faster start being more familiar and confident about product usage

If your development process facilitates communication and collaboration between developers/team members...

you'll create more powerful products in terms of architecture and stability

If your process can't be broken by skipping quality rules...

your team skills will grow faster and resulting quality won't be affected

If your team members could improve development workflow...

they'd become more responsible for approaching their tasks

How it looks in practice

Possible environments for Drupal development● Local DEV (local developer’s desktop)

● Feature Build (CI server) *

● Static build environments (POC, long term testing feature) *optional

● Remote DEV (Accumulated environment for current master branch) *optional

● Staging (Showroom for a client and UAT)

● Production

* Average project outgoings for having CI builds are

● 20-80 $/month hosting● 35 hours of CI maintenance

Possible Drupal 8 development flows1. Profile - deployment is reinstall a project from scratch. Useful for:

a. Initial project creation

b. Develop API, library, module, installation suite(platform)

c. Drupal.org module maintainer environment

d. Develop unit/behat tests with demo content

2. SQL - deployment is fetch/keep SQL data from Live environment and run needed

updates. Useful for:

a. Content Managers need to prefill a database with a real content data

b. Pre launch timeline, testing deployments with ability to keep database data between them

c. Service Level Agreement period

d. Legacy CMS(non-Drupal) projects

e. Acceptance testing

Profile flow how-to* - local/remote environmentUsing CIBox -> http://cibox.tools

> git pull && vagrant up && sh reinstall.sh Or ansible-playbook reinstall.yml -i 'localhost,' --

connection=local

Using drush -> http://drush.ws

> git pull && drush site-install $profile_name $options

Using drupal console -> http://drupalconsole.com

> git pull && drupal site:install [arguments] [options]

* Depends from project specifics but still - install a site takes from 30 seconds to 15 minutes. Best time is not more than 10 minutes.

SQL flow how-to* - local environmentUsing CIBox -> http://cibox.tools

> git pull && vagrant up && sh reinstall.sh

Or ansible-playbook reinstall.yml -i 'localhost,' --connection=local

Using drush -> http://drush.ws

> git pull && drush sql-drop && drush sqlc < dump.sql && prepare settings.php && drush updb

Using drupal console -> http://drupalconsole.com

> git pull && drupal database:drop && drupal database:restore && prepare settings.php && drupal update:

execute

* Depends from project specifics but still - install a site takes from 3 to a lot of minutes. Best time is not more than 10 minutes.

SQL flow how-to* - remote environment (DEV or STAGE)Using CIBox -> http://cibox.tools

Using drush or drupal console, manual style...

1. Deploy the codebase

2. Import working database (It should be previously sanitized from client’s sensitive data) -> optional

3. Prepare settings.php -> optional

4. Run update database

5. Import configs if they weren’t imported by hook_update_N

6. Enable development options, modules

* Depends from project specifics but still - install a site takes from 3 to any amount of minutes. Best time is not more than 10 minutes.

SQL flow how-to* - creating feature branch dev buildsUsing CIBox -> http://cibox.tools

1. Create GitHub Pull Request(PR) with changes to be tested.

2. Prefill steps for review

3. Wait for the comment with a link to a dedicated site build. Under the

hood:

a. CI server gets codebase from PR into unique subfolder/subdomain

within CI server vhost

b. Run reinstall.sh with overridden variables for applying CI

environment

c. Run sniffers.sh and tests.sh for checking code quality

Why is it helpful? e.g. CIBox stats...Projects for 1000+ hours deliver:

● local dev environment is a deploy ~4000 builds.

● CI builds - deploys. generate 2000+ builds.

● remote DEV - deploy as well. ~200 deploys/project

● Staging ~100 deploys

● Production ~50 deploys (~0.5% failed).

Everything executed via reinstall.yml on all environments. Only environment variables

differs in between. Average deploy run is 6 minutes.

The most tested process for CI enabled flows is delivery.

All delivery, devops scripts should be put into the project for team access/development.

Steps for review -> User Guides

Manual CodeReview

Profit!!!

To sum up:● If delivery is an atomic operation - you can move and control development really

fast

● Having virtualized environments helps you get rid of versions nightmare

● Getting builds for a features gives your team a powerful distributed network IDE

● Single Button Deploy makes it fast and easy to be executed by literally anyone

● Putting your automation scripts into the project’s codebase get’s your team a full

control over delivery without sticking to one guy or department

● Having CI server gives you an ability to work remotely

● Manual code review makes your team more skilled and fluent about a project

● Steps for review make your QA/PM/BA and Product Owner as happy as they

should be

Welcome to attend codesprint 05 June 2016

At Sunday we are going

to sprint about CI !!!!

All we need is your brain

B U I L D S

Builds are everywhere!!!

Thanks for your time and attention

Andrii Podanenko

FFW http://ffwagency.com

CIBox http://cibox.tools

Team Lead, Architect.

http://dgo.to/@podarok

Questions?