2016/11/9 sh-ogawa
*
*
*DevOps
*CIについて
*CIのはじめかた
*現場におけるCIとの付き合い方
*
*対立しがちなDev(開発)とOps(運用)を分けて考
えるのではなく、DevとOpsが寄り添ったり協調
し合うことで、ソフトウェアはビジネスにもっ
と貢献できるはず。
という思想
*
*それぞれの思惑
Dev:価値ある機能をどんどん追加して
システムの価値を上げたい人たち
Ops:システムの安定稼働が第一な人たち
*
*それぞれの思惑
Dev:価値ある機能をどんどん追加して
システムの価値を上げたい人たち
Ops:システムの安定稼働が第一な人たち
対立関係にある
*
とはいえ、
DevもOpsも
「システムによってビジネスの価値をより高める
だけでなく、そのビジネスの価値をより確実かつ
迅速にエンドユーザーに届け続ける」
という根底の思いの部分は同じ(はず)
*
お互い目指すものは同じだから、
一緒に頑張って協調しようぜ!
とFlickrがツールと組織文化の観点から提示した
ものがDevOps(の起源っぽい)
*
DevOpsを支えるツールとは、
*インフラを自動化するためのもの
*開発と保守を並行で行うためのバージョン管理システム
*ワンステップビルド&デプロイで安全デリバリ
*フィーチャーフラグで機能の有効無効を制御
*ソフトウェアメトリクスの共有(技術的負債など)
*Botによるアラートなどの検知
*
組織文化とは
*お互いを尊重する
*お互いを信頼する
*失敗に対して健全な態度を取る
*相手を非難しない
自分の言葉で置き換えてみると、
*自分が一番できないヤツだと心の底から思えるマインド
※卑屈になるのはNG
*失敗はチャレンジした結果であると、組織が認める器量
図にするとこんな感じ(ぱくった)
間違いを恐れずに要約してみると、
*開発するときは、自分たちが運用するつもりで、
運用できそうなものを、しっかりと開発しよう
*ソフトをリリースするときには、
人の手を排除できるものは全て排除して、リリースツー
ルに任せよう
(定型の行動ならば、人よりも機械の方が信用できるよ)
*運用中は、どんな使われ方をされているのか、どんな不
具合がよく発生しているのかを収集・分析して
開発へフィードバックしよう
そうしたら、開発が使われていない機能は削除したり、
利用者が喜ぶ機能を追加してくれる
(つまり、一番上のプロセスに戻ってスパイラルが起きる)
*
*
DevOpsを支えるツールとは、
*インフラを自動化するためのもの
*開発と保守を並行で行うためのバージョン管理システム
*ワンステップビルド&デプロイで安全デリバリ
*フィーチャーフラグで機能の有効無効を制御
*ソフトウェアメトリクスの共有(技術的負債など)
*Botによるアラートなどの検知
*
DevOpsを支えるツールとは、
*インフラを自動化するためのもの
*開発と保守を並行で行うためのバージョン管理システム
*ワンステップビルド&デプロイで安全デリバリ ← コレ!
*フィーチャーフラグで機能の有効無効を制御
*ソフトウェアメトリクスの共有(技術的負債など)
*Botによるアラートなどの検知
*ワンステップビルド
&デプロイ
ワンステップビルド&デプロイ
していないプロジェクトにおける
よくある例
*ワンステップビルド
&デプロイ
*入念にレビュー・検証されたリリース手順書を準備する
*印鑑貰いに偉い人を巡るスタンプラリーの実施
*リリースビルド用のマシン(があればまだマシだが。。)
上で、作ったプログラムをリリース用にコンパイル
*コンパイルして生成された.soなり.jarをリリース先のマシ
ンのどこかにコピー
*リリース手順書通りにソフトのリリースを実施
*ワンステップビルド
&デプロイ
はい、とっても怠いです。
*ワンステップビルド
&デプロイ
この方法に何が問題があるかというと
*スタンプラリーが疲れる
*ビルド対象を間違える可能性がある(複数環境ある場合)
*どれだけ念入りに作成した手順書をベースにして作業をし
ても、人の手で操作するためミスが起きるときは起こって
しまう
*サーバが複数台あると、同じ作業を何度もしないといけな
い(怠いし、その分操作を間違えるリスクが増える)
*ワンステップビルド
&デプロイ
でもちょっと考えてみてください。
作業手順書って結局はコマンドの羅列ですよね?
これって、ソフトウェアに置き換えることが可能だと
は思いませんか?
ビルドについても、結局はコマンドの羅列ですよね。
これって、ソフトウェアに置き換えることが可能だと
は思いませんか?
*ワンステップビルド
&デプロイ
ビルドもデプロイも全部一緒にできたら、
色々と楽になりますよ、と。
*ワンステップビルド
&デプロイ
・・・(゜o゜)
CIの勉強会のつもりが、CDの話になってしまった・・・。
*ワンステップビルド
&デプロイ
が、誰も来ないようなので、
このまま言い切っちゃいます。
*ワンステップビルド
&デプロイ
ビルドとデプロイをコード化してしまって、
プログラムで自動で行うことはCDの手法です。
*ワンステップビルド
&デプロイ
CDっていうと、
コンパクトディスク
継続的デリバリ(Continuous Delivery)と、
継続的デプロイメント(Continuous Deployment)
っていう言葉がIT業界ではここ数年よく出てきます。
*ワンステップビルド
&デプロイ
CDっていうと、
コンパクトディスク
継続的デリバリ(Continuous Delivery)と、 ←主にこっちのこと
継続的デプロイメント(Continuous Deployment)
っていう言葉がIT業界ではここ数年よく出てきます。
*ワンステップビルド
&デプロイ
意味は、
*継続的デリバリは、
ソフトウェアをいつでもビルド&デプロイ可能な状態に
しておいて、好きなときにリリースする
*継続的デプロイメントは、
ソフトウェアをいつでもビルド&デプロイ可能な状態に
しておいて、定常的にリリースする
*ワンステップビルド
&デプロイ
継続的デリバリと継続的デプロイメントのどちら
が良いかは、システム次第ではある。
が、定常的にリリースするようなシステムは
見たことないです。
*ワンステップビルド
&デプロイ
けど、いっつもリリースしているってことは、
いつでもリリースできるということですよね。
*ワンステップビルド
&デプロイ
てなわけで、こんな感じで取り組むと良いです
*ワンステップビルド
&デプロイ
*開発中
→継続的デプロイメントでガンガンビルド&デプロイして、
リリースする仕組みの品質を上げしておく
*サービスイン後(もしくは直前)
→継続的デプロイメントから、
継続的デリバリに切り替えて、リリース時の安寧を得る
*ワンステップビルド
&デプロイ
リリースの信頼が上がると、
「リリース?
タイミングの良いところでやれば良いんじゃね?ご自由に。」
*ワンステップビルド
&デプロイ
と、まではいかないまでも
リリースのハードルは爆下げします。
また、リリースがソフトウェアによって行われるため、
リリース作業の属人化から解放されて、
つまらない仕事をする時間が減ります。
*ワンステップビルド
&デプロイ
そろそろ今日の本題に入ろうと思います
(長かった・・・)
*ワンステップビルド
&デプロイ
と、その前に何でこんな話になってしまったかという
言い訳を・・・
*ワンステップビルド
&デプロイ
CDを実現するためには、CIが必要です。
CIするのにCDは要りませんが、
CDするためには、CIは必須なものになります。
*ワンステップビルド
&デプロイ
CDはビルド&デプロイをソフトウェアで行いますが、
これを行うためには、ビルドするプログラムの品質を担
保する必要がありますよね?
*ワンステップビルド
&デプロイ
CDはビルド&デプロイをソフトで行いますが、
これを行うためには、ビルドするプログラムの品質を担
保する必要がありますよね?
ここにCIを使う
本題に入ります
CIとは・・・
*
作ったソフトウェアの
品質を維持する手段です
どうやって行うかというと、
に支援してもらいます。
Jenkinsじゃなくても良いけど、
会社もJenkins使ってるとこが多いし、
Jenkins有名だから
Jenkins使います。
ちなみに紳士です。
紳士だけど
ちゃんと面倒見ないと
こうなることも
Jenkinsを使って何をするかというと、
*定期的な単体テストの実行
*定期的なビルド
*何かやらせたい仕事(最終的にはデプロイさせたい)
CIをやっていないプロジェクトでよく出る問題
時間も経っているため、何起因でエラーになったのかスグに判らない!
そもそもの対応方針が間違っていたとしたら、後戻りが大きい!
CIを行うと・・・
修正した機能のリアルな影響がスグにフィードバックされるため、
スグに軌道修正できる!
*
*ソフト全体の品質の維持&手戻りリスクの削減
*作ったソフトに自信を持てる(リリース時の精神の安定を我が手に!)
*ソフトのリリースを待っているお客さんに動くものを提供できる
*ずっと面倒を見ないといけないシステムにおいて、
ソフトウェアのメンテナンスが楽になる
*攻撃的なリファクタリングが可能
*
*CIを行うためには前提条件があるため、
企業文化によっては、新規開発以外は始めづらい
(※社内案件は問答無用でやるべき)
*何でもかんでもCIに組込んでやらせすぎると後々ツライ
*カットオーバとか言っちゃうプロジェクトや、
短期型プロジェクトには向かない
(テストコードを書く工数が無駄)
*
以下のモノが必須です
*単体テストコード
*Make、ANTなど、自分で頑張ってライブラリファイル
を紐づける系のコンパイルをしているところは、
ビルドスクリプト
*Make、ANTなど使っている場合は、
大抵の場合はCI環境への使用MWのインストール
*忘れてたけど、おじさん(Jenkins)のインストール
*
以下のモノが必須です
*単体テストコード ← はじめるための最大の障壁
*Make、ANTなど、自分で頑張ってライブラリファイル
を紐づける系のコンパイルをしているところは、
ビルドスクリプト
*Make、ANTなど使っている場合は、
大抵の場合はCI環境への使用MWのインストール
*忘れてたけど、おじさん(Jenkins)のインストール
*
とりあえず、テストコードがあればCIは始められます。
更に導入を楽にさせるためには、
*ANT → MavenやGradleなどライブラリの依存関係を自動で解
決してくれるビルドの仕組みを取り入れる
CIを最終的にCDと連携させる場合(最終目標は必ずコレ!)は、
*Subversion → Gitなどの分散バージョン管理に切り替える
※CDまでしなくても、CIの恩恵はGitの方が大きく受けられる
*
Maven/Gradleなどへの乗り換え方
*参照しているライブラリのバージョンを確認しながら、ひ
たすらソフトウェア構造を定義するファイルに書きまくる
*可能であれば、社内にライブラリ管理を行うためのリポジ
トリサーバ(Maven Repositoryのローカル版)を立ち上げる
※スモールスタートでは不要だが、要員が増えたり、
全社標準、最終的に作ったソフトを置く場合は必須
*
Gitへの乗り換え方
*git svn fetchで乗り換える(前回の内容)
http://qiita.com/hidekuro/items/4727715fbda
8f10b6b11
*CI/CD前提でGitを使う場合は、
Subversionの考え方は通用しないので、
しっかりとメンバーを教育しよう
*
そんなこんなで、CIをはじめるためには、
*テストコードを書く(必須)
*ビルドはMavenやGradleを使う(推奨)
*ソース管理はGitなどの分散バージョン管理を使う(推奨)
*おじさん(Jenkins)入れる(必須)
をやると良い
*
おじさんを入れるには、
*Linux・・・yumで入れるとソッコー終わる
http://qiita.com/sh-ogawa/items/120b3c0eef93e48a862a
*Mac・・・homebrew使えばソッコー終わる
*Windows・・・インストーラ叩くと勝手に終わる
1ステップで終わるので、
とっても簡単におじさんがあなたの元にやってきます。
*
で、余力があったら
*テスト結果やソースコードの状態を可視化する
統合品質管理ソフトのSonarQubeを入れてCIと連携する
http://qiita.com/sh-ogawa/items/fac0eca110c3558dfae9
*ライブラリ管理を行ってコンパイルした成果物を保存する
http://qiita.com/sh-ogawa/items/26bd4edb2eff5787ca75
ここまで出来たら、CIのレベルとしてはかなり良い感じ。
*
言葉でどうやって使うのか説明するよりも、
実際に見せた方が速いので
この場でデモ・・・
*
ベーシックなところは大体言ってしまいましたが、
*単体テストコードの定期的な実行
※モックの使用を許可したテストコードの実行
*結合テストコードの定期的な実行
※モックを使わないテストコードの実行
プロジェクトによっては、単体テストコード相当になる
*テストコード実行時のカバレッジの取得
*リリースビルド
*
もうちょっと進んでいるところは、
*単体テストコードの定期的な実行
※モックの使用を許可したテストコードの実行
*結合テストコードの定期的な実行
※モックを使わないテストコードの実行
プロジェクトによっては、単体テストコード相当になる
*テストコード実行時のカバレッジの取得
*リリースビルド
*ソースコードの統合的な品質チェック
*
使い倒しているところは、
*単体テストコードの定期的な実行
※モックの使用を許可したテストコードの実行
*結合テストコードの定期的な実行
※モックを使わないテストコードの実行
プロジェクトによっては、単体テストコード相当になる
*テストコード実行時のカバレッジの取得
*リリースビルド
*ソースコードの統合的な品質チェック
*デプロイの実行
*
ちなみに、Jenkinsのユニークな使い方をしているところだと、
*バッチの実行基盤
*シェル叩かせるだけ
みたいなところもあるみたいです。
超簡易サーバレスとか出来ちゃいそう
(貧弱そうなので、システムに組み込む勇気はないが)
*
そろそろ疲れて来ましたが、
僕の関わる現場でCIをどのように活用したかを
説明します。
*
マスタリングビルド職人より(https://www.gitbook.com/book/uga/mastering-builder)
*
マスタリングビルド職人より(https://www.gitbook.com/book/uga/mastering-builder)
この部分
*
Gitのブランチ
master version feature
*
Gitのブランチ
master version feature
ベースリポジトリ
にマージするブランチ
*
Gitのブランチ
master version feature
ベースリポジトリ
にマージする単位を表す
ブランチ(バージョン番号
を付ける)
git-flowのdevelop相当
*
Gitのブランチ
master version feature
ベースリポジトリ
にマージする単位を表す
ブランチに入れる機能を
開発するブランチに入れ
込む
*
開発の進み方
master version feature
checkout -b
checkout -b
commit
merge/pull req
merge
*
質問:
Gitのブランチでソフトウェアの品質を死守した
いポイントはどこでしょう?
master version feature
*
Gitのブランチでソフトウェアの品質を死守した
いポイントはどこでしょう?
master version feature
ここ
*
Gitのブランチでソフトウェアの品質を死守した
いポイントはどこでしょう?
master version feature
なので、ここをCIと連携させ
て継続的にテストする
*
Gitのブランチでソフトウェアの品質を死守した
いポイントはどこでしょう?
master version feature
なんでこっちではないか?
*
ベースリポジトリにマージ直前にテストを実行し
て、エラーが出ると手戻りが大きい。
masterブランチはクリーンな状態(ビルド可能)
を保ちたい。
*
マスタリングビルド職人より(https://www.gitbook.com/book/uga/mastering-builder)
この部分
*
Gitのブランチ
masterdev stage product
*
Gitのブランチ
masterdev stage product
サイトリポジトリで単体テスト・レ
ビュー・CIのテストなど一通りクリアし
たものがマージされるブランチ
(確実にビルド可能)
このブランチから開発環境にデプロイし
てテストする(結合試験を想定)
*
Gitのブランチ
masterdev stage product
結合試験してOKだった場合に、dev
からマージされるブランチ。
ステージング環境にデプロイして
テストする(総合試験を想定)
*
Gitのブランチ
masterdev stage product
総合試験してOKだった場合に、
stageからマージされるブランチ。
本番環境にデプロイしてリリース
する。またMaven(Archaiva)リポジ
トリにデプロイした一式を保存し
ておく。
*
Gitのブランチ
masterdev stage product
本番環境にリリースしたものを保持し
ておくリポジトリ
(保持だけで何もしない)
*
Gitのブランチ
masterdev stage product
Jenkinsから、
各ブランチに対応した環境に対応したモジュールをビルド
&デプロイするようにしておく
(CDの部分)
*
Gitのブランチ
masterdev stage product
本番環境にリリースしたものを保持し
ておくリポジトリ
(保持だけで何もしない)
質問ですが、
これってどう思います
か??
*
Gitのブランチ
masterdev stage product
サイトリポジトリから
merge/pull req
merge
merge
merge
*
Gitのブランチ
masterdev stage product
サイトリポジトリから
merge/pull req
merge
merge
merge
各フェーズをクリアしたものを
横のブランチに移していくことで、
コンフリクトやマージ漏れを防いで
迅速にリリースまで持っていく
*
Gitのブランチ
masterdev stage product
本番環境にリリースしたものを保持し
ておくリポジトリ
(保持だけで何もしない)
これの意味は、
次回リリースの最後の最後まで、確実に動いたソース一
式を保持しておき、いざとなったらmasterからproductを
上書きして元に戻すために存在する最後の砦
*
こうしておくことで、
元に戻すときに、
この場合の対応は、hogehoge
この場合は、hogehoge2
など考えなくて済む。
シンプルに元に戻して配って終わり。
まとめ
*
CIとは・・・
*CIはソフトウェアの品質を担保するための手段の一つ
*保守し続けるシステムには必須
*Gitとの親和性が高い
*CDとの懸け橋になる
(これメインだったんじゃないかという資料に・・・)
ご静聴ありがとうございました。

DevOpsを支える技術勉強会(CI編)