CI workflow in a web studio
Transcript of CI workflow in a web studio
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.
Step 3Learn 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
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 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 14Scripts improvements
- Move Drupal files to docroot
- Create reinstal.sh
- Move all settings to settings.sh
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 rsync
files folder)
5. Send link somewhere
6. Profit!
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
5. 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