Drupal開発環境構築 アプリCI/CD編

2019年3月20日 Drupal Meetup 豊田 #5 「Drupal開発環境構築 アプリCI/CD編」での発表スライド

keywords: Drupal, CMS, CI/CD, git, GitLab, Docker

Transcript

1. Drupal開発環境構築 アプリCI/CD編 2019.3.20 Drupal Meetup 豊⽥ #5 @豊⽥中央研究所 ことラボ 代表 ⼩松⾼廣
2. 撮影・シェアOKです
 スライドは後ほど
 https://kotolab.jp にて掲載します
3. ⾃⼰紹介 - ⼩松⾼廣（こまつたかひろ） - ことラボ 代表 - フリーランスエンジニア - 修⼠:公⽴はこだて未来⼤学⼤学院
 システム情報科学研究科 複雑系情報科学領域
4. ࡳຈ വؗ
6. 公⽴はこだて未来⼤学
7. 就職@東京 ソフトウェア開発
  →ハードウェア開発へ 無線機・マイコン機器の開発 安否確認システム
 ヘルパーコールなど福祉機器の開発
8. ことラボ
9. ひとにしかできないこと。 あなたを⽀える、ことづくり。
10. モノ視点 <=> コト視点
11. モノやサービスだけでなく
 ⼈の役に⽴つ仕組み = システム
 を作りたい
12. 事業内容 - 電⼦機器開発 - アプリケーションソフトウェア開発 - ネットワークシステム構築 - ホームページ制作 - 名刺・パンフレット制作
13. 楽しい開発案件
 ぜひ紹介してください
14. 難聴者の
 補聴⽀援システム
15. ⽇本でどれぐらいの⼈が難聴？ 厚⽣労働省 “平成23年 ⽣活のしづらさに関する調査 （全国在宅障害児・者等実態調査）” 20dB 以下 25 〜 39dB 40 〜 69dB 70 〜 89dB 90dB 以上 WHO 障害者
 ⼿帳 ⼈⼝⽐5% = 約635万⼈ ໿24ສਓ WHO “Deafness and hearing loss” 2015年 約611万⼈
16. ヒアリングループ ⾳声情報 （電気） マイク ループ線 ⾳声情報 （磁気） 聞く ループアンプ
17. ヒアリングループを
 受信できる機器 補聴器
 （Tモード付） 専⽤受信機 ⼈⼯内⽿ https://ja.wikipedia.org/wiki/⼈⼯内⽿
18. ヒアリングループのマーク
19. Facebookάϧʔϓʮו܊Ί͔ͩͷֶߍ ʯ https://www.facebook.com/groups/g.medaka/ - 難聴者が難聴者を⽀援 する団体 - 毎⽉第1⼟曜⽇に集 まってヒアリングルー プ・⾳声認識システム の研究をしている
20. 難聴者⽀援を通して
 社会の「聞こえ」に対する
 考え⽅を変えていきたい
21. Drupal
22. Drupal(ドゥルーパル) - CMS(Contents Management System)
 WordPress, Joomula! に次ぐシェア - PHPで書かれている
 Symfony2フレームワークをベースにしている - 最新バージョン 8シリーズ
 2019/3/19時点 8.6.12 - 個⼈的にはCMSとして⾒るよりもPHPアプリケーションフ レームワークとして⾒ることに意味があると感じている
23. 世界のCMSシェア率 その他 12.2% Drupal 1.9% Joomla! 2.9% WordPress 33.4% 不明 44.6% 2019/3/19⽇現在 IUUQTXUFDITDPNUFDIOPMPHJFT
 IJTUPSZ@PWFSWJFXDPOUFOU@NBOBHFNFOUBMM
24. Webサイト・Webアプリ どうやって作っていますか？
25. サイト制作⽅法の変遷 - がんばって全てをタグ打ちする - パーツ(ヘッダ/フッタ)を共通化する - 動的にサイトを⽣成する - 共通化された機能(ログイン/管理画 ⾯)を誰でも楽に使えるように
26. MVCモデル Model View Controller ユーザ データ調整 リクエスト 要求伝達 データ要求 ページ提供 データ
27. お店でご飯を⾷べる 農家(DB) 給仕(HTTP) 料理⼈(APP) ユーザ 調理 オーダー 注⽂伝達 野菜要求 料理提供 野菜納⼊
28. MVCモデル MySQL Apache Drupal ブラウザ データ調整 リクエスト 要求伝達 データ要求 ページ提供 データ
29. なぜCMSを使うのか - 同じ作業を何度もしたくない
 どのページでも使うパーツの作成
 誰でも使う機能の開発 - コピペして作った量だけ修正する量も増える - コンテンツを管理することよりも
 コンテンツを作ることに集中したい
30. サイト作りは
 意外とやること多い
31. どんどん⾃動化しないと
 マンパワーでは解決が難しい
32. ⼀番の問題は
33. あまりに作り込みをすると
 改修するときの
 フットワークが重くなる
34. 安全性が求められるものほど
 部品を変更するのは⼤変
35. CI/CD
36. CI 継続的インテグレーション - Continuous Integration - 丁寧に時間をかけて作ったもの同⼠を組み合わせ て1つにして本当に⼤丈夫かどうか？を確かめる (テストをする)のはすごく⼤変 - たくさんの⼩さなパーツ（Webサイトの場合は外 観パーツ・機能パーツ)を常に新しく作ってどんど ん組み込んでいけるよう統合作業を⾃動化したい
37. CD 継続的デリバリー/デプロイ - Continuous Delivery - Continuous Deploy - ユーザへ常に新しいもの(=Webサイ トでの体験)をどうやって届ける か？を⾃動化したい
38. CI/CDのステージ ビルド 結合テスト コーディング デプロイ パッケージ ユニットテスト リリース CI CD
39. 具体的には
 どうしたらいい？
40. CI/CDを実現するために - パーツ管理の仕組みを変えてみる
 誰でも情報を辿って理解できるようにする - テストを⾃動化する
 ⼈はミスをする⽣き物 - アプリ/動作環境の可搬性を⾼める
 どこでも動くようにする
41. パーツ
 = コード
 = ファイル
42. ファイル名で管理するのは⼤変 - ⽇付をつける⼈もいる
 20190320code.txt
 20190327code.txt … - 末尾に数字を⼊れる⼈も
 code_1.txt
 code_2.txt … - いずれにしても「何がどうして変更されたか？」を 後から⾒た時や他の⼈には分からないという問題
43. コメントを書くことは もちろん⼤切
44. なぜそうしたのか？
 の履歴を辿れることが⼤切
45. バージョン管理システム
 を使おう！
46. git
47. 使ってますか？
48. git(ギット) - Linuxカーネルのソースコード管理⽤に作られた OSSのバージョン管理システム - リモートリポジトリ+ローカルリポジトリを持てる ので分散開発がしやすい(できるだけ同期的に) - テキストデータであれば差分を簡単に取ることが できるので変遷を楽に確認できる
 (バイナリデータはブランチを適度に削除するなど うまく管理しないとデータ量が⼤変なことになる)
49. リモートリポジトリ ローカルリポジトリ 開発 プル プッシュ コミット PC サーバ
50. リモートリポジトリ
51. リポジトリ内の流れ
 =ブランチ戦略
52. master 機能1 1.0 バグ 機能2 1.1 2.0 3.0
53. バージョン管理システムの可能性 - コード以外にもバージョン管理したいものは 意外とたくさんある
 回路図・3Dデータ・仕様書・契約書… - テキスト形式にして書けるものは何でもバー ジョン管理システムとすごく親和性が⾼い
54. GitHub - gitのリポジトリをホスティングするサービス - 現在はMicrosoftが運⽤している - 無料ユーザでも公開リポジトリは好きなだけ作成可能 - 2019年1⽉から無料ユーザでも⾮公開リポジトリを いくらでも作成可能になった
 (ただし無料ユーザの場合には共同編集者が3名まで 等のいろいろな制限がある)
55. GitLab - gitのリポジトリを管理するためのアプリケー ション - OSSのコミュニティ版はオンプレミスで運⽤可能
 (スペックを要求するのでVPSにやや不向き) - GitHub同様にGUIを提供してくれるのでCUIが 苦⼿な⼈にも使いやすい
57. GitLabのCI/CD機能(1) - GitLab Runner
 GitLabが管理するリモートリポジトリに対する操作を トリガーとして、あらかじめ設定したコードを⾃動的に 実⾏できる - Runnerを使うと
 プッシュ/マージ + ビルド + ユニットテスト
 まで⾃動化可能 - GitHub + CIツール(Jenkins/Travis CI/ Circle CI)でも同様のことは可能
58. CI/CDのステージ ビルド 結合テスト プッシュ/マージ デプロイ パッケージ ユニットテスト リリース CD React Sass ↓ .js .css CI
59. GitLabのCI/CD機能(2) - GitLab CI/CD Pipeline - ステージ間を逐次処理 - ステージ内を並列処理
60. CI/CDのステージ ビルド 結合テスト プッシュ/マージ デプロイ パッケージ ユニットテスト リリース CD CI
61. CI/CDツールのメリット - シェルスクリプトをがんばって書けば同じこと はもちろんできる - シェルスクリプトの汎⽤性は⾼いが属⼈的コー ドになりやすく可読性を維持するのが難しい - なにより「冪等性」を保証するのがすごく⼤変
62. 冪等性(べきとうせい) - 同じ処理をもう1度適⽤しても⼤丈夫である こと - 既にその処理がされているかどうかをチェッ クしながら実⾏するコードを書くのは⼤変労 ⼒がかかる
63. ⾃動化に求められる要件 - ユーザはどうやってそれが実現されているの かを気にしなくていい - あるべき状態を「⼿続的」ではなく
 「宣⾔的」に書くと再現性が⾼い
 cf.料理のレシピ・関数型プログラミング
64. カプセル化 - 「どうやって実現されているか」をユーザが知 らないと使えない状況は情報がうまくカプセル 化されていない - エンジンやトランスミッションの構造を知らな くても⾃動⾞は運転できる - コンパイラや半導体の原理を知らなくてもコン ピュータは使える
65. ご飯が1つある状態にしてください ご飯を1つ追加してください ≠ 宣⾔的な注⽂ ⼿続的な注⽂
66. ご飯を1つ追加してください システム ユーザ 注⽂が通っているかどうか常に確認が必要！
67. ⼿続的な記述は
 履歴がないと
 次の状態がどうなるか分からない
68. ご飯が1つある状態にしてください システム ユーザ どれだけ注⽂しても⼤丈夫
69. CI/CDのポイント
70. 宣⾔的に記述 かつ
 容易に持ち運び可能
 にすること
71. そのためにツールを
 使って⾃動化する
72. Docker
73. - OSのカーネル空間を共有しつつユーザ空間 を仮想的に分離して提供するOSS - アプリケーションのコードだけではなく
 動作環境も含めてまるごとパッケージしたも の(Dockerイメージ)を持ち運びできる - Dockerfileをgitで管理すると
 Dockerイメージの作り込みを防げる
74. 開発⽤PC環境と
 サーバ環境の
 差異も吸収できる
75. 開発環境の差異 開発⽤PC サーバ ハードウェア macOS Apache Drupal MySQL ハードウェア CentOS Apache Drupal MySQL 開発したコードが 本当に本番サーバで動く？
76. コンテナ化 開発⽤PC サーバ ハードウェア macOS Apache Drupal MySQL ハードウェア CentOS Apache Drupal MySQL 開発コード+ミドルウェア を
 パッケージング(コンテナ化)して持ち運ぶ
77. でも同じサーバ環境を
 何個も作るのは
 ちょっとしんどい…
78. アプリCI/CD インフラCI/CD
79. というわけで 次回はインフラCI/CD
80. ⼤事なのは
81. ツールを使うことが⽬的ではなく
 開発効率を上げることが⽬的
82. ⾃分の状況に合わせて
 少しずつ取り⼊れながら
 より良い開発環境構築へ！
83. ご清聴ありがとう
 ございました
84. https://kotolab.jp ことラボ