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

*
*DevOps
*CIについて
*CIのはじめかた
*現場におけるCIとの付き合い方

*
*対立しがちなDev(開発)とOps(運用)を分けて考
えるのではなく、DevとOpsが寄り添ったり協調
し合うことで、ソフトウェアはビジネスにもっ
と貢献できるはず。
という思想

*
*それぞれの思惑
Dev：価値ある機能をどんどん追加して
システムの価値を上げたい人たち
Ops：システムの安定稼働が第一な人たち

*
*それぞれの思惑
Dev：価値ある機能をどんどん追加して
システムの価値を上げたい人たち
Ops：システムの安定稼働が第一な人たち
対立関係にある

*
とはいえ、
DevもOpsも
「システムによってビジネスの価値をより高める
だけでなく、そのビジネスの価値をより確実かつ
迅速にエンドユーザーに届け続ける」
という根底の思いの部分は同じ(はず)

*
お互い目指すものは同じだから、
一緒に頑張って協調しようぜ！
とFlickrがツールと組織文化の観点から提示した
ものがDevOps(の起源っぽい)

*
DevOpsを支えるツールとは、
*インフラを自動化するためのもの
*開発と保守を並行で行うためのバージョン管理システム
*ワンステップビルド＆デプロイで安全デリバリ
*フィーチャーフラグで機能の有効無効を制御
*ソフトウェアメトリクスの共有(技術的負債など)
*Botによるアラートなどの検知

*
組織文化とは
*お互いを尊重する
*お互いを信頼する
*失敗に対して健全な態度を取る
*相手を非難しない
自分の言葉で置き換えてみると、
*自分が一番できないヤツだと心の底から思えるマインド
※卑屈になるのはNG
*失敗はチャレンジした結果であると、組織が認める器量

図にするとこんな感じ(ぱくった)

間違いを恐れずに要約してみると、
*開発するときは、自分たちが運用するつもりで、
運用できそうなものを、しっかりと開発しよう
*ソフトをリリースするときには、
人の手を排除できるものは全て排除して、リリースツー
ルに任せよう
(定型の行動ならば、人よりも機械の方が信用できるよ)
*運用中は、どんな使われ方をされているのか、どんな不
具合がよく発生しているのかを収集・分析して
開発へフィードバックしよう
そうしたら、開発が使われていない機能は削除したり、
利用者が喜ぶ機能を追加してくれる
(つまり、一番上のプロセスに戻ってスパイラルが起きる)

*
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のブランチ
ベースリポジトリ
にマージするブランチ

*
Gitのブランチ
にマージする単位を表す
ブランチ(バージョン番号
を付ける)
git-flowのdevelop相当

*
Gitのブランチ
にマージする単位を表す
ブランチに入れる機能を
開発するブランチに入れ
込む

*
開発の進み方
checkout -b
checkout -b
commit
merge/pull req
merge

*
質問：
Gitのブランチでソフトウェアの品質を死守した
いポイントはどこでしょう？

*
ここ

*
なので、ここをCIと連携させ
て継続的にテストする

*
なんでこっちではないか？

*
ベースリポジトリにマージ直前にテストを実行し
て、エラーが出ると手戻りが大きい。
masterブランチはクリーンな状態（ビルド可能）
を保ちたい。

*
Gitのブランチ
masterdev stage product

*
Gitのブランチ
サイトリポジトリで単体テスト・レ
ビュー・CIのテストなど一通りクリアし
たものがマージされるブランチ
（確実にビルド可能）
このブランチから開発環境にデプロイし
てテストする（結合試験を想定）

*
Gitのブランチ
結合試験してOKだった場合に、dev
からマージされるブランチ。
ステージング環境にデプロイして
テストする（総合試験を想定）

*
Gitのブランチ
総合試験してOKだった場合に、
stageからマージされるブランチ。
本番環境にデプロイしてリリース
する。またMaven(Archaiva)リポジ
トリにデプロイした一式を保存し
ておく。

*
Gitのブランチ
本番環境にリリースしたものを保持し
ておくリポジトリ
（保持だけで何もしない）

*
Gitのブランチ
Jenkinsから、
各ブランチに対応した環境に対応したモジュールをビルド
＆デプロイするようにしておく
(CDの部分)

*
Gitのブランチ
質問ですが、
これってどう思います
か？？

*
Gitのブランチ
サイトリポジトリから
merge/pull req
merge
merge
merge

*
Gitのブランチ
サイトリポジトリから
merge/pull req
merge
merge
merge
各フェーズをクリアしたものを
横のブランチに移していくことで、
コンフリクトやマージ漏れを防いで
迅速にリリースまで持っていく

*
Gitのブランチ
これの意味は、
次回リリースの最後の最後まで、確実に動いたソース一
式を保持しておき、いざとなったらmasterからproductを
上書きして元に戻すために存在する最後の砦

*
こうしておくことで、
元に戻すときに、
この場合の対応は、hogehoge
この場合は、hogehoge2
など考えなくて済む。
シンプルに元に戻して配って終わり。

*
CIとは・・・
*CIはソフトウェアの品質を担保するための手段の一つ
*保守し続けるシステムには必須
*Gitとの親和性が高い
*CDとの懸け橋になる
（これメインだったんじゃないかという資料に・・・）

ご静聴ありがとうございました。

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

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

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

Plus de 小川昌吾

Plus de 小川昌吾 (20)