Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
ITの開発現場における 最近の当たり前 これからの当たり前(主観) 2017/11/09 sh-ogawa
はじめに DevOpsが話題になって早数年。 弊社でもクラウド利用を推進しているため、巷でも知見が多いCI/CDからはじめたい。 だいぶPHPとかLaravelにも慣れてきたので、そっちも出来るかな・・・と
はじめに DevOpsが話題になって早数年。 弊社でもクラウド利用を推進しているため、巷でも知見が多いCI/CDからはじめたい。 だいぶPHPとかLaravelにも慣れてきたので、そっちも出来るかな・・・と 根回し + 仲間募集会です！！
DevOpsからCI、CDと周りを喋って、 じゃあ弊社ではどうやる展望があるのか？ というところまでを駆け足で
駆け足・・・
スライド１３０枚くらいになっちゃったので
( ;∀;)詰め込み過ぎた・・・
で、お前何が判るの？
DevOps歴 ■ DevOps完遂経験は勿論ない ■ CIは2011年くらいから ■ CDは2014年くらいから（シェルだった）
DevOpsとは
DevOps・・・それは思想
Dev・・・開発 Ops・・・運用
Dev(開発) 価値ある機能をどんどん追加したいし、 良いツールはどんどん取り込んでプロダ クトに活かしたい。 それぞれの思惑 Ops(運用) システムの安定稼働が一番。
Dev(開発) 価値ある機能をどんどん追加したいし、 良いツールはどんどん取り込んでプロダ クトに活かしたい。 →チャレンジして価値を届けたいと思っ ている人たち。 それぞれの思惑 Ops(運用) システムの安定稼働が一番。 →システムが安定す...
対立している・・・
言葉は違えど目指している姿は一緒だと思う
価値（機能追加、バグフィックス）を届けたい・・・
それも速く
目指すべきものが同じなら協調しよう！ とFlickrがツールと組織文化から提示
DevOps = ツール + 組織文化
DevOpsツール ■ インフラ構築を自動化するためのもの ■ 開発と保守を並行で行うためのバージョン管理 ■ ワンステップビルド＆デプロイ ■ フィーチャーフラグで機能の有効無効を制御 ■ ソフトウェアメトリクスの共有 ■ Botやモニタリン...
DevOpsツール ■ インフラ構築を自動化するためのもの →ansible ■ 開発と保守を並行で行うためのバージョン管理 →git ■ ワンステップビルド＆デプロイ →CI tools(Jenkins, TravisCI、CircleCI、...
DevOpsツール ■ インフラ構築を自動化するためのもの →ansible ■ 開発と保守を並行で行うためのバージョン管理 →git ■ ワンステップビルド＆デプロイ →CI tools(Jenkins, TravisCI、CircleCI、...
DevOps 分化 ■ お互いを尊重する ■ お互いを信頼する ■ 失敗に対して健全な態度を取る ■ 相手を非難しない
DevOps 分化 ■ お互いを尊重する ■ お互いを信頼する ■ 失敗に対して健全な態度を取る ■ 相手を非難しない 賢者かよ！？って感じの項目が並んでますが、 外から来た目で見て、 かなりできているように視えてます（すごい！）
ここまで結構長いけど、これが前提の話です
本題
CIから～
Continuous Integration 継続的インテグレーション
はじめて聞いた人の大体の反応・・・
意味不明( ；´Д｀)
作ったソフトウェアの 品質を維持する手段
ソフトウェアのリリースは、借金をすることと同義
リリースすることによってかかる費用 ■ バグフィックス ■ 機能追加 ■ サーバー運用費 ■ トラブル対応 ■ 利用者へのサポート etc...
これらはサービスをクローズするまで払い続けなくてはいけない
プログラムは長く運用するほど、デカく難解になっていく
そもそもプログラミングした人が居なくなる可能性もある
だが、人類には自動テストがある！
自動テストとは ■ 繰り返し行うようなテストをコードで記載して時短する手段 ■ ある処理の動作をINとOUTをセットでコードとして保存する
自動テストとは ■ 繰り返し行うようなテストをコードで記載して時短する手段 →機械は同じ処理が大好き ■ ある処理の動作をINとOUTをセットでコードとして保存する →ソースいじって結果が変われば検知可能
自動テスト ■ 静的テスト ・コードのスタイルチェック ・バイナリレベルでのチェック ■ 動的テスト ・テストコードの記述 （xUnit系、PHPならPHPUnitとか） ・結合テストコードの記述 ・UIテストコード ・パフォーマンステスト e...
自動テストとは何のためにやるのか？
自動テストをやる理由 ■ 新しく入ってきた人にシステムを託すため ■ ソフトウェアの振る舞いが変わったことを検知するため
自動テストをやる理由 ■ 新しく入ってきた人にシステムを託すため ■ ソフトウェアの振る舞いが変わったことを検知するため ■ レグレッションテストで楽したい（開発者目線）
自動テストをやる理由 ■ 新しく入ってきた人にシステムを託すため →動くもので仕様を把握できる ■ ソフトウェアの振る舞いが変わったことを検知するため →カバレッジの変化で思わぬ変更を捕捉する ■ レグレッションテストで楽したい（開発者目線） ...
テストコードの雰囲気はこんな感じ(PHPUnit)
/** * @test */ public function 足し算の確認() { $test_class = new Target(); $this->assertEquals(3, $test_class->add(1, 2)); }
/** * @test */ public function 足し算の確認() { $test_class = new Target(); $this->assertEquals(3, $test_class->add(1, 2)); }
テストコードの詳細はこちらを・・・ https://www.slideshare.net/sh-ogawa/ss-72206317
人類に自動テストがあるとはいえ、 個人PCの中で実行させると嬉しさ半減
なぜか？
全部のテストコード流すと、プログラミングの邪魔 そもそも個人で全てのテストを流す理由がない
だからテスト専用機にやらせる
CIサーバー
無人だから誰もストレスに感じない
CIサーバーにやらせること ■ セントラルリポジトリにチェックインされたコードの自動テ ストの実行 （プルリク時にテストさせることも可能） ■ テスト結果のレポーティング ■ Slackなどへ結果を通知
ひと昔前だったら、これだけでも満足できた
今はDevOpsのハブになって貰わないと困る
エンジニアにとってリリース作業はツマラナイ
なのでリリースを自動化する
CDの出番！
Continuous Delivery 継続的デリバリー
Continuous Deployment 継続的デプロイメント
平たく言うと、 リリース可能なソフトウェアを 好きなタイミングでリリースする取り組み
リリース可能なソフトウェア = 確実に動くソフト
Gitのブランチを活用する
ブランチ戦略はプロジェクトの在り方を表す
ブランチの基本セット (Githubフローもこんな感じ) ■ 機能の開発：feature,hotfix,issueなど ■ 開発用マスタ：version番号 ■ 結合環境：develop ■ 本番相当の確認環境：staging ■ 本番環境：p...
デリバリーの仕方はオンプレとクラウドで異なる
オンプレ 変えたいものだけをリリース 関係あるものだけ差し替えたい リリース方法 クラウド ぶっ壊すこと前提 リリースとはマシンごと用意すること
オンプレ 変えたいものだけをリリース 関係あるものだけ差し替えたい 自動化するのも骨が折れる リリース方法 クラウド ぶっ壊すこと前提 リリースとはマシンごと用意すること それ、Ansibleなら簡単かもよ？
Ansible
Ansible Simple 設定ファイル(YAML) 雰囲気Linuxコマンド Powerfull 冪等性の担保 Agentless 構築先の環境構築不要
Ansibleの構成 ■ インベントリファイル（どこに構築する？） ■ プレイブック（構築方法）
インベントリファイル [webservers] 192.168.33.10 [dbservers] 192.168.33.11 ファイルの例 プレイブック - name: 全環境に適応するプレイブック hosts: all tasks: - n...
設定ファイルの書き方を覚えるだけでサーバー作れる
冪等性の担保・・・あまり信じない方が良い
Ansibleの位置付け ■ インフラのコード化が捗る ■ インフラを構築するための便利なシェル if $?とかしなくてOK
どこまで細かくイケる？
Ansibleで対応できること ■ システム１つ丸々構築できる ■ WEBサーバーだけ、DBサーバーだけ、限定的に構築可能 ■ AWSのEC2も作れる ■ 設定ファイルは上書きから、特定の行の変更、付け足しなど 割と何でもできる
インフラをコード化すると そのテストができるということ
Serverspecを使う
Serverspecでできること ■ ミドルウェアが入っているか ■ サービスが登録されているか ■ 正しいポート番号でリッスンしているか ■ 構成ファイルが存在しているか など
ただ、これ使っても正しさは担保できない
インフラは変わっていく可能性がある
Serverspecでできること ■ ミドルウェアが入っているか ■ サービスが登録されているか ■ 正しいポート番号でリッスンしているか ■ 構成ファイルが存在しているか など これくらい確認しとけば十分
サービスを稼働するために必要最低限をチェックしてれば、 インフラの変更で動かなくなる部分をケアできる
余談というか、私的なこれからのアプリエンジニア像
インフラのコード化スキルは、 これからのアプリエンジニアの必須スキル
なんで、まぁAnsibleやろう！（仲間募集）
一旦まとめ
CI（継続的インテグレーション） ■ ソフトウェアの品質を維持するためのプラクティス これ自体が何かするわけではない ■ テストコードを書いておくと、好きな方法で実行できる ■ DevOpsのハブである
CD（継続的デリバリー） ■ 好きなときに、実行可能なソフトをリリースするプラクティス ■ 類似のもので、定常的にリリースをし続ける 継続的デプロイメントがある ※海外だと何となくこちらの意味合いの方が強そう ■ CIから起動される
ぶっちゃけ・・・
CIとCDを分けて語る必要を最近感じない・・・
今現在は、「パイプライン」が主流
パイプライン ■ 単体で完結するジョブを繋いだもの
パイプラインのジョブとは ■ SCMからチェックアウト ■ テストコードを実行 ■ テストコードの結果とカバレッジの保存 ■ ソフトウェアのデプロイ ■ インフラの構築 ■ Dockerコンテナのビルド ■ 任意シェルの実行 など、コマンドでで...
パイプラインのジョブとは ■ SCMからチェックアウト ■ テストコードを実行 ■ テストコードの結果とカバレッジの保存 ■ ソフトウェアのデプロイ ■ インフラの構築 ■ Dockerコンテナのビルド ■ 任意シェルの実行 など、コマンドでで...
CI/CDはパイプライン上で全部説明した方がしっくりくる
パイプライン（GUI） 参考資料：https://jenkins.io/images/post-images/blueocean/pipeline-run.png
パイプライン（制御コードの書き方） 参考資料：https://github.com/sh-ogawa/jenkins-files/blob/master/junit-sonar- script/Jenkinsfile node { stage(...
パイプライン（制御コードの書き方） 参考資料：https://github.com/sh-ogawa/jenkins-files/blob/master/junit-sonar- script/Jenkinsfile node { stage(...
パイプライン（実行のさせ方）
パイプラインの良いところ ■ SCMで管理可能 ■ コードで記載されているから何をやっているかも雰囲気で判る ■ タスクが死んだ場合、どこで死んだか一目で判る
パイプラインを使わない手はないです
Infrastructure as Codeは インフラを育てること前提
従来 ApachePHP MySQL
似たような作業が毎回発生
従来 ApachePHP MySQL 各種アップデ ートよろお
バージョンアップのリハーサルとかを死ぬ気でやる
クラウドを前提としたときのあるべき姿 Ansible ロール(WebServer、DB Server)を全部作 り込む。Try＆エラー
クラウドを前提としたときのあるべき姿 Vagrant Ansible Vagrant環境上に本番環境と同等のネッ トワーク構成で環境を作り出す
クラウドを前提としたときのあるべき姿 Vagrant Ansible 開発が一通り終わる頃には、 信頼できるplay-bookが育っている
クラウドを前提としたときのあるべき姿 Ansible Vagrant 育てたplay-bookで サーバー環境を作り出す
各種アップデ ートよろお
クラウドを前提としたときのあるべき姿 Ansible ここに書いてあるバージョンを書き換えて、 Vagrantからロードして一通りやり直す
クラウドを前提としたときのあるべき姿 Vagrant Ansible このとき、PHPUnitでテストコードを入念に 書いていると、テストコードを実行するだけ で、１次診断が終わる。（超時短）
クラウドを前提としたときのあるべき姿 Ansible Vagrant ステージング環境にAnsibleで新しくサー バーを作って、止まったら困る機能を打 鍵で確認してあげればリリースに向けて 一先ず安心
新しくサーバーを作るのがミソ
だが、この辺のやり方までの知見はまだ 持ってない！
なんで、まぁ下期はこの辺を本気で取り組んでいきたい所存 ※”Immutable Infrastructure ansible”で調べると沢山出てくる
下期ロードマップ パイプラインで リリースの全自 動化 AWS上に全自動 で環境構築 今やってる Vagrantを ansibleプロビジ ョニングできる ように
緩募：一緒にやる人
プレイブックを作ることは、未来への投資に繋がる
１度作ったプレイブックは、新しくサービスを作るときの 開発環境構築でも勿論使える
なので、みんなAnsibleやろう！
ご静聴ありがとうございました。
ITの開発現場における最近の当たり前これからの当たり前（主観）
Prochain SlideShare
Chargement dans…5
×
Ingénierie
417 vues
9 nov. 2017

ITの開発現場における最近の当たり前これからの当たり前（主観）

社内勉強会の固有名詞削ったヤツ。
再アップロードできないから、消してやり直した！

no profile picture user

  • Identifiez-vous pour voir les commentaires

ITの開発現場における最近の当たり前これからの当たり前（主観）

  1. 1. ITの開発現場における 最近の当たり前 これからの当たり前(主観) 2017/11/09 sh-ogawa
  2. 2. はじめに DevOpsが話題になって早数年。 弊社でもクラウド利用を推進しているため、巷でも知見が多いCI/CDからはじめたい。 だいぶPHPとかLaravelにも慣れてきたので、そっちも出来るかな・・・と
  3. 3. はじめに DevOpsが話題になって早数年。 弊社でもクラウド利用を推進しているため、巷でも知見が多いCI/CDからはじめたい。 だいぶPHPとかLaravelにも慣れてきたので、そっちも出来るかな・・・と 根回し + 仲間募集会です！！
  4. 4. DevOpsからCI、CDと周りを喋って、 じゃあ弊社ではどうやる展望があるのか？ というところまでを駆け足で
  5. 5. 駆け足・・・
  6. 6. スライド１３０枚くらいになっちゃったので
  7. 7. ( ;∀;)詰め込み過ぎた・・・
  8. 8. で、お前何が判るの？
  9. 9. DevOps歴 ■ DevOps完遂経験は勿論ない ■ CIは2011年くらいから ■ CDは2014年くらいから（シェルだった）
  10. 10. DevOpsとは
  11. 11. DevOps・・・それは思想
  12. 12. Dev・・・開発 Ops・・・運用
  13. 13. Dev(開発) 価値ある機能をどんどん追加したいし、 良いツールはどんどん取り込んでプロダ クトに活かしたい。 それぞれの思惑 Ops(運用) システムの安定稼働が一番。
  14. 14. Dev(開発) 価値ある機能をどんどん追加したいし、 良いツールはどんどん取り込んでプロダ クトに活かしたい。 →チャレンジして価値を届けたいと思っ ている人たち。 それぞれの思惑 Ops(運用) システムの安定稼働が一番。 →システムが安定することで、 ユーザーのビジネスなどが成功する はずと思っている人たち。
  15. 15. 対立している・・・
  16. 16. 言葉は違えど目指している姿は一緒だと思う
  17. 17. 価値（機能追加、バグフィックス）を届けたい・・・
  18. 18. それも速く
  19. 19. 目指すべきものが同じなら協調しよう！ とFlickrがツールと組織文化から提示
  20. 20. DevOps = ツール + 組織文化
  21. 21. DevOpsツール ■ インフラ構築を自動化するためのもの ■ 開発と保守を並行で行うためのバージョン管理 ■ ワンステップビルド＆デプロイ ■ フィーチャーフラグで機能の有効無効を制御 ■ ソフトウェアメトリクスの共有 ■ Botやモニタリングによるアラート検知
  22. 22. DevOpsツール ■ インフラ構築を自動化するためのもの →ansible ■ 開発と保守を並行で行うためのバージョン管理 →git ■ ワンステップビルド＆デプロイ →CI tools(Jenkins, TravisCI、CircleCI、etc) ■ フィーチャーフラグで機能の有効無効を制御 →実装レベルでの制御 ■ ソフトウェアメトリクスの共有 →SonarQube ■ Botやモニタリングによるアラート検知 →slack、zabbix、prometheus、mackerel、etc
  23. 23. DevOpsツール ■ インフラ構築を自動化するためのもの →ansible ■ 開発と保守を並行で行うためのバージョン管理 →git ■ ワンステップビルド＆デプロイ →CI tools(Jenkins, TravisCI、CircleCI、etc) ■ フィーチャーフラグで機能の有効無効を制御 →実装レベルでの制御 ■ ソフトウェアメトリクスの共有 →SonarQube ■ Botやモニタリングによるアラート検知 →slack、zabbix、prometheus、mackerel、etc
  24. 24. DevOps 分化 ■ お互いを尊重する ■ お互いを信頼する ■ 失敗に対して健全な態度を取る ■ 相手を非難しない
  25. 25. DevOps 分化 ■ お互いを尊重する ■ お互いを信頼する ■ 失敗に対して健全な態度を取る ■ 相手を非難しない 賢者かよ！？って感じの項目が並んでますが、 外から来た目で見て、 かなりできているように視えてます（すごい！）
  26. 26. ここまで結構長いけど、これが前提の話です
  27. 27. 本題
  28. 28. CIから～
  29. 29. Continuous Integration 継続的インテグレーション
  30. 30. はじめて聞いた人の大体の反応・・・
  31. 31. 意味不明( ；´Д｀)
  32. 32. 作ったソフトウェアの 品質を維持する手段
  33. 33. ソフトウェアのリリースは、借金をすることと同義
  34. 34. リリースすることによってかかる費用 ■ バグフィックス ■ 機能追加 ■ サーバー運用費 ■ トラブル対応 ■ 利用者へのサポート etc...
  35. 35. これらはサービスをクローズするまで払い続けなくてはいけない
  36. 36. プログラムは長く運用するほど、デカく難解になっていく
  37. 37. そもそもプログラミングした人が居なくなる可能性もある
  38. 38. だが、人類には自動テストがある！
  39. 39. 自動テストとは ■ 繰り返し行うようなテストをコードで記載して時短する手段 ■ ある処理の動作をINとOUTをセットでコードとして保存する
  40. 40. 自動テストとは ■ 繰り返し行うようなテストをコードで記載して時短する手段 →機械は同じ処理が大好き ■ ある処理の動作をINとOUTをセットでコードとして保存する →ソースいじって結果が変われば検知可能
  41. 41. 自動テスト ■ 静的テスト ・コードのスタイルチェック ・バイナリレベルでのチェック ■ 動的テスト ・テストコードの記述 （xUnit系、PHPならPHPUnitとか） ・結合テストコードの記述 ・UIテストコード ・パフォーマンステスト etc...
  42. 42. 自動テストとは何のためにやるのか？
  43. 43. 自動テストをやる理由 ■ 新しく入ってきた人にシステムを託すため ■ ソフトウェアの振る舞いが変わったことを検知するため
  44. 44. 自動テストをやる理由 ■ 新しく入ってきた人にシステムを託すため ■ ソフトウェアの振る舞いが変わったことを検知するため ■ レグレッションテストで楽したい（開発者目線）
  45. 45. 自動テストをやる理由 ■ 新しく入ってきた人にシステムを託すため →動くもので仕様を把握できる ■ ソフトウェアの振る舞いが変わったことを検知するため →カバレッジの変化で思わぬ変更を捕捉する ■ レグレッションテストで楽したい（開発者目線） →毎回行う儀式的な確認からの解放
  46. 46. テストコードの雰囲気はこんな感じ(PHPUnit)
  47. 47. /** * @test */ public function 足し算の確認() { $test_class = new Target(); $this->assertEquals(3, $test_class->add(1, 2)); }
  48. 48. /** * @test */ public function 足し算の確認() { $test_class = new Target(); $this->assertEquals(3, $test_class->add(1, 2)); }
  49. 49. テストコードの詳細はこちらを・・・ https://www.slideshare.net/sh-ogawa/ss-72206317
  50. 50. 人類に自動テストがあるとはいえ、 個人PCの中で実行させると嬉しさ半減
  51. 51. なぜか？
  52. 52. 全部のテストコード流すと、プログラミングの邪魔 そもそも個人で全てのテストを流す理由がない
  53. 53. だからテスト専用機にやらせる
  54. 54. CIサーバー
  55. 55. 無人だから誰もストレスに感じない
  56. 56. CIサーバーにやらせること ■ セントラルリポジトリにチェックインされたコードの自動テ ストの実行 （プルリク時にテストさせることも可能） ■ テスト結果のレポーティング ■ Slackなどへ結果を通知
  57. 57. ひと昔前だったら、これだけでも満足できた
  58. 58. 今はDevOpsのハブになって貰わないと困る
  59. 59. エンジニアにとってリリース作業はツマラナイ
  60. 60. なのでリリースを自動化する
  61. 61. CDの出番！
  62. 62. Continuous Delivery 継続的デリバリー
  63. 63. Continuous Deployment 継続的デプロイメント
  64. 64. 平たく言うと、 リリース可能なソフトウェアを 好きなタイミングでリリースする取り組み
  65. 65. リリース可能なソフトウェア = 確実に動くソフト
  66. 66. Gitのブランチを活用する
  67. 67. ブランチ戦略はプロジェクトの在り方を表す
  68. 68. ブランチの基本セット (Githubフローもこんな感じ) ■ 機能の開発：feature,hotfix,issueなど ■ 開発用マスタ：version番号 ■ 結合環境：develop ■ 本番相当の確認環境：staging ■ 本番環境：production ■ 最近無くても良い気がしてきた：master
  69. 69. デリバリーの仕方はオンプレとクラウドで異なる
  70. 70. オンプレ 変えたいものだけをリリース 関係あるものだけ差し替えたい リリース方法 クラウド ぶっ壊すこと前提 リリースとはマシンごと用意すること
  71. 71. オンプレ 変えたいものだけをリリース 関係あるものだけ差し替えたい 自動化するのも骨が折れる リリース方法 クラウド ぶっ壊すこと前提 リリースとはマシンごと用意すること それ、Ansibleなら簡単かもよ？
  72. 72. Ansible
  73. 73. Ansible Simple 設定ファイル(YAML) 雰囲気Linuxコマンド Powerfull 冪等性の担保 Agentless 構築先の環境構築不要
  74. 74. Ansibleの構成 ■ インベントリファイル（どこに構築する？） ■ プレイブック（構築方法）
  75. 75. インベントリファイル [webservers] 192.168.33.10 [dbservers] 192.168.33.11 ファイルの例 プレイブック - name: 全環境に適応するプレイブック hosts: all tasks: - name: install open-jdk yum: name=java-1.8.0-openjdk-headless.x86_64 state=present
  76. 76. 設定ファイルの書き方を覚えるだけでサーバー作れる
  77. 77. 冪等性の担保・・・あまり信じない方が良い
  78. 78. Ansibleの位置付け ■ インフラのコード化が捗る ■ インフラを構築するための便利なシェル if $?とかしなくてOK
  79. 79. どこまで細かくイケる？
  80. 80. Ansibleで対応できること ■ システム１つ丸々構築できる ■ WEBサーバーだけ、DBサーバーだけ、限定的に構築可能 ■ AWSのEC2も作れる ■ 設定ファイルは上書きから、特定の行の変更、付け足しなど 割と何でもできる
  81. 81. インフラをコード化すると そのテストができるということ
  82. 82. Serverspecを使う
  83. 83. Serverspecでできること ■ ミドルウェアが入っているか ■ サービスが登録されているか ■ 正しいポート番号でリッスンしているか ■ 構成ファイルが存在しているか など
  84. 84. ただ、これ使っても正しさは担保できない
  85. 85. インフラは変わっていく可能性がある
  86. 86. Serverspecでできること ■ ミドルウェアが入っているか ■ サービスが登録されているか ■ 正しいポート番号でリッスンしているか ■ 構成ファイルが存在しているか など これくらい確認しとけば十分
  87. 87. サービスを稼働するために必要最低限をチェックしてれば、 インフラの変更で動かなくなる部分をケアできる
  88. 88. 余談というか、私的なこれからのアプリエンジニア像
  89. 89. インフラのコード化スキルは、 これからのアプリエンジニアの必須スキル
  90. 90. なんで、まぁAnsibleやろう！（仲間募集）
  91. 91. 一旦まとめ
  92. 92. CI（継続的インテグレーション） ■ ソフトウェアの品質を維持するためのプラクティス これ自体が何かするわけではない ■ テストコードを書いておくと、好きな方法で実行できる ■ DevOpsのハブである
  93. 93. CD（継続的デリバリー） ■ 好きなときに、実行可能なソフトをリリースするプラクティス ■ 類似のもので、定常的にリリースをし続ける 継続的デプロイメントがある ※海外だと何となくこちらの意味合いの方が強そう ■ CIから起動される
  94. 94. ぶっちゃけ・・・
  95. 95. CIとCDを分けて語る必要を最近感じない・・・
  96. 96. 今現在は、「パイプライン」が主流
  97. 97. パイプライン ■ 単体で完結するジョブを繋いだもの
  98. 98. パイプラインのジョブとは ■ SCMからチェックアウト ■ テストコードを実行 ■ テストコードの結果とカバレッジの保存 ■ ソフトウェアのデプロイ ■ インフラの構築 ■ Dockerコンテナのビルド ■ 任意シェルの実行 など、コマンドでできること全て
  99. 99. パイプラインのジョブとは ■ SCMからチェックアウト ■ テストコードを実行 ■ テストコードの結果とカバレッジの保存 ■ ソフトウェアのデプロイ ■ インフラの構築 ■ Dockerコンテナのビルド ■ 任意シェルの実行 など、コマンドでできること全て
  100. 100. CI/CDはパイプライン上で全部説明した方がしっくりくる
  101. 101. パイプライン（GUI） 参考資料：https://jenkins.io/images/post-images/blueocean/pipeline-run.png
  102. 102. パイプライン（制御コードの書き方） 参考資料：https://github.com/sh-ogawa/jenkins-files/blob/master/junit-sonar- script/Jenkinsfile node { stage('update') { git([url: 'https://github.com/sh-ogawa/auto-test-demo.git', branch: 'sonar']) } stage('test') { bat 'mvn clean jacoco:prepare-agent test jacoco:report -e | echo "ignore failure"' } stage('analyze') { bat 'mvn sonar:sonar -e' } }
  103. 103. パイプライン（制御コードの書き方） 参考資料：https://github.com/sh-ogawa/jenkins-files/blob/master/junit-sonar- script/Jenkinsfile node { stage('update') { git([url: 'https://github.com/sh-ogawa/auto-test-demo.git', branch: 'sonar']) } stage('test') { bat 'mvn clean jacoco:prepare-agent test jacoco:report -e | echo "ignore failure"' } stage('analyze') { bat 'mvn sonar:sonar -e' } } 使用するCIツールによって書き方は勿論違うけど、 基本的にリファレンス見ながら書くだけなので、実行自体は難しくない。 ※難しい（というか手間がかかる）のは、その中身の制御（AnsibleのプレイブックとかDockerfile）を書くこと。 ちなみに例のJenkinsパイプラインスクリプトはGroovy（私Groovyなど書いたことないですが、これは書けます）
  104. 104. パイプライン（実行のさせ方）
  105. 105. パイプラインの良いところ ■ SCMで管理可能 ■ コードで記載されているから何をやっているかも雰囲気で判る ■ タスクが死んだ場合、どこで死んだか一目で判る
  106. 106. パイプラインを使わない手はないです
  107. 107. Infrastructure as Codeは インフラを育てること前提
  108. 108. 従来 ApachePHP MySQL
  109. 109. 似たような作業が毎回発生
  110. 110. 従来 ApachePHP MySQL 各種アップデ ートよろお
  111. 111. バージョンアップのリハーサルとかを死ぬ気でやる
  112. 112. クラウドを前提としたときのあるべき姿 Ansible ロール(WebServer、DB Server)を全部作 り込む。Try＆エラー
  113. 113. クラウドを前提としたときのあるべき姿 Vagrant Ansible Vagrant環境上に本番環境と同等のネッ トワーク構成で環境を作り出す
  114. 114. クラウドを前提としたときのあるべき姿 Vagrant Ansible 開発が一通り終わる頃には、 信頼できるplay-bookが育っている
  115. 115. クラウドを前提としたときのあるべき姿 Ansible Vagrant 育てたplay-bookで サーバー環境を作り出す
  116. 116. 各種アップデ ートよろお
  117. 117. クラウドを前提としたときのあるべき姿 Ansible ここに書いてあるバージョンを書き換えて、 Vagrantからロードして一通りやり直す
  118. 118. クラウドを前提としたときのあるべき姿 Vagrant Ansible このとき、PHPUnitでテストコードを入念に 書いていると、テストコードを実行するだけ で、１次診断が終わる。（超時短）
  119. 119. クラウドを前提としたときのあるべき姿 Ansible Vagrant ステージング環境にAnsibleで新しくサー バーを作って、止まったら困る機能を打 鍵で確認してあげればリリースに向けて 一先ず安心
  120. 120. 新しくサーバーを作るのがミソ
  121. 121. だが、この辺のやり方までの知見はまだ 持ってない！
  122. 122. なんで、まぁ下期はこの辺を本気で取り組んでいきたい所存 ※”Immutable Infrastructure ansible”で調べると沢山出てくる
  123. 123. 下期ロードマップ パイプラインで リリースの全自 動化 AWS上に全自動 で環境構築 今やってる Vagrantを ansibleプロビジ ョニングできる ように
  124. 124. 緩募：一緒にやる人
  125. 125. プレイブックを作ることは、未来への投資に繋がる
  126. 126. １度作ったプレイブックは、新しくサービスを作るときの 開発環境構築でも勿論使える
  127. 127. なので、みんなAnsibleやろう！
  128. 128. ご静聴ありがとうございました。

×