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

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

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

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

E0a89ea965a4ac4b5f091d6bd9e8d8ea?s=128

Takahiro Komatsu

March 20, 2019
Tweet

Transcript

  1. Drupal開発環境構築 アプリCI/CD編 2019.3.20 Drupal Meetup 豊⽥ #5 @豊⽥中央研究所 ことラボ 代表

    ⼩松⾼廣
  2. 撮影・シェアOKです
 スライドは後ほど
 https://kotolab.jp にて掲載します

  3. ⾃⼰紹介 - ⼩松⾼廣(こまつたかひろ) - ことラボ 代表 - フリーランスエンジニア - 修⼠:公⽴はこだて未来⼤学⼤学院


    システム情報科学研究科 複雑系情報科学領域
  4. ࡳຈ വؗ

  5. None
  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が 苦⼿な⼈にも使いやすい

  56. None
  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 ことラボ