11月28日(水)開催のニフクラミートアップでお話したスライドです。

1. 今さら聞けない人のための
CI/CD超入門
日本仮想化技術株式会社
代表取締役社長兼CEO
宮原 徹(@tmiyahar)
http://VirtualTech.jp

2. 自己紹介
• 本名：宮原 徹
• 1972年1月 神奈川県生まれ
• 1994年3月 中央大学法学部法律学科卒業
• 1994年4月 日本オラクル株式会社入社
– PCサーバ向けRDBMS製品マーケティングに従事
– Linux版Oracle8の日本市場向け出荷に貢献
• 2000年3月 株式会社デジタルデザイン 東京支社長および株
式会社アクアリウムコンピューター 代表取締役社長に就任
– 2000年6月 （株）デジタルデザイン、ナスダック・ジャパン上場（4764）
• 2001年1月 株式会社びぎねっと 設立
• 2006年12月 日本仮想化技術株式会社 設立
• 2008年10月 IPA「日本OSS貢献者賞」受賞
• 2009年10月 日中韓OSSアワード 「特別貢献賞」受賞
• ガンダム勉強会主宰・好きなモビルスーツはアッガイ
2

3. 3
『Software Desgin』で毎月
「宮原徹のオープンソース放浪記」連載中

4. 日本仮想化技術株式会社 概要
• 社名：日本仮想化技術株式会社
– 英語名：VirtualTech Japan Inc.
– 略称：日本仮想化技術／VTJ
• 設立：2006年12月
• 資本金：3,000万円
• 売上高：10,702万円（2017年7月期）
• 本社：東京都渋谷区渋谷1-8-1
• 取締役：宮原 徹（代表取締役社長兼CEO）
• 伊藤 宏通（取締役CTO）
• スタッフ：9名（うち、7名が仮想化技術専門エンジニアです）
• URL：http://VirtualTech.jp/
• 仮想化技術に関する研究および開発
– 仮想化技術に関する各種調査
– 仮想化技術に関連したソフトウェアの開発
– 仮想化技術を導入したシステムの構築
– OpenStackの導入支援・新規機能開発
ベンダーニュートラルな
独立系仮想化技術の
エキスパート集団
4

5. DevOpsを支える技術
CI/CDを中心に

6. DevOpsを支える要素・技術
• 自動化
– テストの自動化
– インフラ構築の自動化
• 効率化
– 継続的インテグレーション(CI)
– 継続的デリバリー(CD)
• チーム開発（共有化？）
– 運用モデルに基づくバージョン管理
– チケット駆動開発によるタスクの明確化
6

7. テスト自動化のメリット
• 短時間でテストが可能
• 手動では困難なテストも容易に
• リソースの有効活用
– システムリソース：夜間などに自動実行
– 人的リソース：繰り返し行うテストで省力化
• テストの品質向上
– 一貫性の保持（属人性の排除）
– 再現性の確保（誰が行っても再現する）
• テストツールの再利用、横展開
7

8. テスト自動化のデメリット
• 初期コストは高い
– 継続的に利用することで費用対効果が上がる
– 要求される仕様に大きな変更が加えられると、
テストコードにも影響する
• テスト自動化は万能ではない
– テストコードを書くのは自分たち
– 書いたコード以上のテストはできない
8

9. 代表的なテスト
• 静的テスト
– プログラムを実行せずコード解析のみでバグ、脆弱性、表記の揺れ等を
チェック
– レビューの自動化
– infer (C/Java/Objective-C)
– RuboCop (Ruby/Rails)
• 単体テスト・ユニットテスト
– 実装した機能（メソッド、モジュール等）単体で仕様通りに動作するか
チェック
– JUnit (Java)
– RSpec (Ruby)
• 統合テスト・結合テスト・エンドツーエンドテスト
– 実装した機能がうまく連携して動作するかチェック
– Selenium (Webアプリ全般)
– Turnip (Ruby/Rails)
– Infrataster (インフラ周り)
9

10. インフラ構築の自動化
• 手順書ベースによる構築の課題
– 手間がかかる
– 設定ミス等が起きやすい
• 自動化ツールによる構築
– 仮想化、コンテナ化、クラウド化により容易に
実現できるようになった
– 誰が何度実行しても同じ結果になる
– 設計書との相違がおきにくくなる
– 障害復旧が容易（再構築）
10

11. 継続的インテグレーション(CI)
• ビルドやテストを短期間で繰り返し行い開発
効率を上げる手法
– 定期的に実行（デイリービルド）
– バグを早期に発見（短期間で繰り返しテスト）
– 他のツールと連動（進捗管理等）
• 代表的なツール
– Jenkins
– GitLab CI
– CircleCI (SaaS)
– Travis CI (SaaS)
11

12. 継続的デリバリー(CD)
• CIの仕組みをインフラ構築まで拡張
– テストした成果物を自動デプロイメント
• インフラ構築自動化と組み合わせることで
短時間で構築可能
– テスト環境と本番環境を同等の構成で構築
– インフラを含めた結合テストを自動化
– コンテナが使われることが多い
12

13. Gitを利用したバージョン管理
• ソースコード等の共有
– 変更履歴を記録、追跡
– 履歴の用途毎に分岐して管理（ブランチ）
– 切り戻しが容易（リベート）
• プルリクエスト機能によりレビューを可視化
• 他のツールとの連携
– Jenkins
– Redmine
13

14. Gitを利用したバージョン管理
A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/
– リリース用と開発用の2つのメインブランチを
用意
– 機能追加、バグフィックス等Issue登録を行う毎
にメインブランチから切り出す
– 問題が起きても本番用ブランチや他の人の開
発には影響しない
– GitLabではプルリクエスト機能によりレビュー
を可視化
14
参考

15. 代表的なブランチモデル
master
hotfix-001
release-ver1
develop
feature-001
feature-002
Ver.0.1 Ver.0.2 Ver.1.0
バグの修正
機能追加
Ver.1プロトタイプ
機能追加
15
参考

16. バージョン管理とCI/CD
• インフラ環境を自動構築しテスト
– クラウドやコンテナを活用
– 本番同様のインフラ環境でテストが可能
• 本番環境へのリリース時も毎回新規構築
– リリース直後に問題が発生した場合でも、旧
環境へすぐに切り戻せる
16

17. CI/CD/DevOpsの範囲
コード修正 静的テスト ビルド
単体テスト /
統合テスト
インフラ構築 /
デプロイメント
本番
運用
継続的インテグレーション(CI)
継続的デリバリー(CD)
DevOps

18. CI/CDを止める要因あるある
• 原因は分からないが止まってる
– 再現性が低く、やり直すとうまくいく
• ネットワークに起因する障害が多い
– ネットワークが疎通しないとあらゆる面で問題
– yumやapt、Dockerのリポジトリが死んでる
– 名前解決関係が要因の場合も
18

19. ありがとうございました
19