How to automate your Drupal 8 team What types of development flow should you select for best results

1. 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.

2. About a speaker
Andrii 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

3. 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)

4. The crucial point for the development is a...
Speed of Delivery

5. If you able to deliver a project for a small amount of time...
you can become a winner in
terms of marketing and
sales

6. If you could demo particular feature any time...
you could give the customers
thoughts they are controlling the
process of developing the product

7. 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

8. 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

9. 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

10. 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

11. If your development process facilitates communication
and collaboration between developers/team members...
you'll create more powerful
products in terms of architecture
and stability

12. If your process can't be broken by skipping quality
rules...
your team skills will grow faster
and resulting quality won't be
affected

13. If your team members could improve development
workflow...
they'd become more responsible
for approaching their tasks

14. How it looks in practice

15. 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

16. Possible Drupal 8 development flows
1. 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

17. Profile flow how-to* - local/remote environment
Using 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.

18. SQL flow how-to* - local environment
Using 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.

19. 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.

20. SQL flow how-to* - creating feature branch dev builds
Using 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

21. 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.

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

23. Steps for review -> User Guides

25. Manual Code
Review

26. Profit!!!

27. 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

28. 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!!!

29. Thanks for your time and attention
Andrii Podanenko
FFW http://ffwagency.com
CIBox http://cibox.tools
Team Lead, Architect.
http://dgo.to/@podarok
Questions?