Тарас Кирилюк та Олена Пустовойт — ci workflow у веб-студії
Post on 29-Jan-2018
197 Views
Preview:
TRANSCRIPT
Development Team StructureOur Production Team
Problems Back-ups. The only thing for your protection;
creating one thing, you can make a mess somewhere else;
yet we know we can make a minor change in 5 min - we have a
lot of them;
you can’t even imagine how many bugs you’ll meet during the
last testing before deadline;
where is our time?!;
while you don’t have rules - your client gives them to you;
panic during deadline/deploy;
Continuous Integration WorkflowCI - is the practice, in software
engineering, of merging all developer working copies to a shared mainline several times a day.
What it gives to you:
- better developing processes;
- smooth deploy process;
- deploy is possible every day.
Continuous Integration Workflow
Step 1. Code Driven Development
Step 2. Understanding of how it works
CI-BOX
CI-BOX DevOps
BACK-END part
Principles
Be lazy
Be productive
The big picture
Step 1
Goodbye old friends!
Step 2
Start working with Console, Learn SSH
Step 3
Learn how to move sites between servers…
1. rsync -avh -e 'ssh -p [port]' [ssh_user]@[server_name]:/path/to/drupal/ ./
2. nano sites/default/settings.php
3. drush sql-drop
4. gunzip < sites/../../../dump_name.mysql.gz | drush sql-cli
Learn how to automate server provisioning
Step 4
Step 5Learn about Vagrant
Step 6
Start working locally
+
Default:
Apache 2.4.x (or Nginx 1.x),
PHP 5.6.x, MySQL 5.5.x, Drush,
Drupal 6.x, 7.x, or 8.x.x.
Other cool stuff:
Varnish 4.x, Apache Solr 4.10.x,
Node.js 0.12,
Selenium, Ruby
Memcached
XHProf, XDebug, Adminer,
Pimp my Log, MailHog
Step 7
Start using Git and Bitbucket
+ pull requests
+ manual Code review
Step 8
Code driven development
- features
- strongarm
- hook_update_N()
Step 9: STAGE + PROD environment
Step 10: Deploy Continuously1. cd /path/to/docroot
2. drush vset maintenance_mode 1
3. drush bb
4. git pull
5. drush rr
6. drush updb -y
7. drush cc all
8. drush vset maintenance_mode 0
Step 11
1. Check if "$HOSTNAME" == "$CURRENT_HOSTNAME" (run it only on DEV)
2. cp local.settings.php settings.php
3. rsync -avh --delete -e "$SSH_OPT" $REMOTE_USER@$REMOTE_SERVER:$PATH_TO_SITEROOT/sites/default/files/ ./sites/default/files
4. drush sql-drop -y
5. BASE_DUMP=$(ls -t $PATH_TO_BM_MANUAL/*.mysql.gz | head -1)
6. gunzip < $BASE_DUMP | drush sql-cli
First DEV-STAGE sync script
Step 12
1. Check if "$HOSTNAME" == "$CURRENT_HOSTNAME" (run it only on STAGE)
2. rsync -avh --delete -e "$SSH_OPT"
$REMOTE_USER@$REMOTE_SERVER:$PATH_TO_SITEROOT/sites/default/files/
./sites/default/files
3. drush sql-drop -y
4. BASE_DUMP=$(ls -t $PATH_TO_BM_MANUAL/*.mysql.gz | head -1)
5. gunzip < $BASE_DUMP | drush sql-cli
First STAGE-PROD sync script
Let's count2 projects at a time
2 servers (STAGE and PROD) on each project to deploy
9 commands to deploy (1 ssh + 8 deploy)
2 * 2 * 9 = 36
Manual actions / day (minimum)
And be sure to don’t mess up anything!
Step 13
Step 14
Scripts improvements
- Move Drupal files to docroot
- Create reinstal.sh
- Move all settings to settings.sh
Testing environment
How to create testing environment?1.Pull files from Bitbucket
2.Get Database dump from STAGE-server
3.Restore database from dump
4.Install Stage File Proxy module (or rsyncfiles folder)
5.Send link somewhere
6.Profit!
The Idea!
Step N
Create script to create testing environments
How it works?1.Jenkins checks Bitbucket repo (by schedule)
2.Jenkins merges branches when there is pull request
3.Jenkins runs BASH script after branches are merged
4.BASH:
- Create folder
- Copy merged files
- Copy base dump from STAGE-server
- Create database and restore dump
- Install Stage File Proxy module
- Post comment on Bitbucket with the link to created site
1.Profit!
Links to the source code:
Local environment (based on Drupal VM):
https://bitbucket.org/deweb-studio/code-driven-starter.kit
Tool to create testing environment:
https://bitbucket.org/deweb-studio/jenkins_ci_drupal
top related