今さら聞けない人のためのGit超入門 OSC2018名古屋版

今さら聞けない人のためのGit超入門 OSC2018名古屋版

1. 1. 今さら聞けない人のための Git超入門 OSC2018名古屋版 日本仮想化技術株式会社 代表取締役社長兼CEO 宮原 徹(@tmiyahar) http://VirtualTech.jp
2. 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. 3 『Software Desgin』で毎月 「宮原徹のオープンソース放浪記」連載中
4. 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の導入支援・新規機能開発・運用サポート – 自動化・DevOps支援 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 4
5. 5. 情報サイト：EnterpriseCloud.jp • OpenStackで始めるエ ンタープライズクラウ ドの情報サイト • OpenStack導入手順 書のダウンロード • 各種プレゼン資料 • その他ブログ記事 5
6. 6. 会社のご紹介 仲間募集のお知らせ
7. 7. 日本仮想化技術株式会社は • 仮想化技術のエキスパート集団 • 進取の精神 • 豊富な検証機材で新技術を追求 • 自由な雰囲気の職場 7
8. 8. 一緒に頑張ってくれる仲間を募集中 • サーバー、ネットワークエンジニア – 新卒からキャリアアップしたい経験者まで – クラウド技術、自動化技術に興味がある人 • コンサルタント – 通信系に強い人大歓迎 • インターン – 学生はもちろん、社会人も可 8
9. 9. どんなオフィス？ •渋谷駅より徒歩5分 •全員がゆったりデスク とアーロンチェア 9
10. 10. オフィスは渋谷駅至近 10 日本仮想化技術 オフィス ハ チ 公 渋谷駅東口 交差点信号 渋 谷 駅 ヒカリエの中を通ると 雨の日にあまり濡れません 渋 谷 郵 便 局
11. 11. 優れた環境が優れた成果を生む 渋谷駅徒歩5分の新オフィス 幅140cmのゆったりデスクとアーロンチェア MacBook Pro/Airと大型液晶モニタが標準 キーボード・マウスも自由 充実の検証環境 最新機材で作業 11
12. 12. 充実の福利厚生 • マッサージチェア • 充実のフリードリンクコーナー – お茶、ネスプレッソなど多種多様に取り揃え • 誕生日はケーキでお祝い • 雑誌年間購読制度 – 何でも好きな雑誌を年間購読 • 書籍購入支援制度 – 技術書の購入は無制限（当然） – 好きな書籍（漫画も可）を1万円／年購入 12
13. 13. お問い合わせ先 メールにて recruit@VirtualTech.jp 履歴書、職務経歴書をご用意ください ご紹介も是非。きっと何かいいことあります。 13
14. 14. 本日のアジェンダ • DevOpsとは？ • Gitを利用した開発モデル • GitLabを使って試してみよう • GitLabにプロジェクトを作成する • DevOpSaaSに向けて • CI/CDを支える中心的な技術であるコード管 理の代表的なGitの使用方法を講師なりに勉 強して仕組みを理解できるように解説します 14
15. 15. DevOpsとは？
16. 16. DevOpsとは？ • 開発と運用が密に連携して協力しあう開発 手法 – DevOpsを支援する技術やツールを積極的に 利用 – 開発は新しい機能を安心してリリースできる – 運用は新しい機能を安心して受け入れられる ↓ 変化に対して前向きに進みやすくする 16
17. 17. DevOpsを支える要素・技術 • 自動化 – テストの自動化 – インフラ構築の自動化 • 効率化 – 継続的インテグレーション(CI) – 継続的デリバリー(CD) • チーム開発（共有化？） – 運用モデルに基づくバージョン管理 – チケット駆動開発によるタスクの明確化 17
18. 18. 継続的インテグレーション(CI) • ビルドやテストを短期間で繰り返し行い開発 効率を上げる手法 – 定期的に実行（デイリービルド） – バグを早期に発見（短期間で繰り返しテスト） – 他のツールと連動（進捗管理等） • 代表的なツール – Jenkins – Atlassian Bamboo – CircleCI (SaaS) – Travis CI (SaaS) 18
19. 19. 継続的デリバリー(CD) • CIの仕組みをインフラ構築まで拡張 – テストした成果物を自動デプロイメント • インフラ構築自動化と組み合わせることで 短時間で構築可能 – テスト環境と本番環境を同等の構成で構築 – インフラを含めた結合テストを自動化 19
20. 20. Gitを利用した開発モデル 20
21. 21. Gitを利用したバージョン管理 • ソースコード等の共有 – 変更履歴を記録、追跡 – 履歴の用途毎に分岐して管理（ブランチ） – 切り戻しが容易 • プルリクエスト（マージリクエスト）機能によ りレビューを可視化 • 他のツールとの連携 – Jenkins – Redmine 21
22. 22. Gitを利用したバージョン管理 A successful Git branching model http://nvie.com/posts/a-successful-git-branching-model/ – リリース用と開発用の2つのメインブランチを 用意 – 機能追加、バグフィックス等Issue登録を行う毎 にメインブランチから切り出す – 問題が起きても本番用ブランチや他の人の開 発には影響しない – GitLabではマージリクエスト機能によりレ ビューを可視化 22
23. 23. git-flowの例 master hotfix-001 release-ver1 develop feature-001 feature-002 Ver.0.1 Ver.0.2 Ver.1.0 機能追加 Ver.1リリース準備 機能追加 23 緊急バグ修正 バグ修正
24. 24. バージョン管理とCI/CD • インフラ環境を自動構築しテスト – クラウドやコンテナを活用 – 本番同様のインフラ環境でテストが可能 • 本番環境へのリリース時も毎回新規構築 – リリース直後に問題が発生した場合でも、旧 環境へすぐに切り戻せる 24
25. 25. CI/CD/DevOpsの範囲 コード修正 静的テスト ビルド 単体テスト / 統合テスト インフラ構築 / デプロイメント 本番 運用 継続的インテグレーション(CI) 継続的デリバリー(CD) DevOps
26. 26. DevOpsのモデルケース • 開発者には簡易的な実行環境 – VirtualBox+Vagrant、Dockerの利用 – 環境構築スクリプトもGit等で共有可能 • Jenkinsサーバーにテストツールと実行環境を構築 – テスト負荷が大きい場合はSlaveを用意 • テスト完了後ステージング環境へデプロイ – インフラの自動構築 – git pullコマンドで更新 • 問題がなければ本番環境へデプロイ – Blue/Green Deployment 26
27. 27. モデル環境について（Ruby） コードの 修正 ローカル Git 本番環境 （Dockerコンテナ） master ブランチ develop ブランチ deploy ジョブ test ジョブ Webアプリ commit push テスト結果を 通知 merge mergeを 検知 コンテナの 作成 pushを 検知 1世代前の 本番環境 更新前の Webアプリ 旧コンテナを 切り替え 27
28. 28. GitLabを使って試してみよう 28
29. 29. デモ環境について 『GitLab実践ガイド』を参考に • CentOS 7.4にGitLab Community Editionを インストール – Enterprise Editionでもライセンスを有効にしな ければCommunity Edition相当 – Omnibusインストールで必要なものがまとまっ て入ります 29
30. 30. GitLabインストール時の注意点 • 「Installation using the Omnibus packages」を参考に 環境を構築 – 普通にインストールページに行くとEEになっている – https://about.gitlab.com/installation/#centos-7 • CEをインストールしたい場合は、上記ページの一 番下の「CE or EE」をクリックし、さらに一番下の 「Install GitLab Community Edition」をクリック – https://about.gitlab.com/installation/#centos- 7?version=ce • ホスト名の決定方法がやや難解です 30
31. 31. CentOS 7.4へのインストール 1. sudo yum install -y curl policycoreutils-python openssh-server 2. sudo systemctl enable sshd 3. sudo systemctl start sshd 4. sudo firewall-cmd --permanent --add-service=http 5. sudo systemctl reload firewalld 6. curl https://packages.gitlab.com/install/repositories/gitl ab/gitlab-ce/script.rpm.sh | sudo bash 7. yum install -y gitlab-ce 31
32. 32. ホスト名の指定と構成変更の適用 • 以下の条件の場合、インストールの最後で自 動的に構成変更が適当される – ホスト名が正しく設定されている – 逆引きDNSでホスト名を返す • 【重要】ホスト名を指定して、構成変更の適用 を行う必要がある – /etc/gitlab/gitlab.rbが設定ファイル • external_url ‘http://gitlab.example.com’ – 設定後再構成を実行 • sudo gitlab-ctl reconfigure 32
33. 33. GitLab関連コマンド • GitLabの起動状態確認 – gitlab-ctl status • GitLabの起動／停止／再起動 – gitlab-ctl start/stop/restart – 後ろに個別のサービス名を付けることも可能 33
34. 34. GitLabにプロジェクトを作成する 34
35. 35. GitLabの管理単位 • ユーザー – 各開発者のアカウント • グループ – ユーザーをまとめた管理単位 • プロジェクト – ソースコードのリポジトリを含めた開発プロ ジェクトに必要なもの一式 – ユーザー、あるいはグループに紐付けられる 35
36. 36. GitLabで初期設定作業 1. http://gitlab.example.comにアクセス 2. ユーザーrootのパスワードを設定 3. ユーザーrootでログイン 4. 新しいユーザーを作成 5. 指定したメールアドレスにメールが届く – http://gitlab.example.comへのリンクが埋め込まれ ている 6. 新規ユーザーのパスワード設定 7. 新規ユーザーでログイン 36
37. 37. ユーザーでプロジェクト作成 ユーザーtmiyaharを作成しています 1. 新規プロジェクトtestを作成 2. リポジトリのURLを確認 3. クライアントにリポジトリをクローン – SourceTree：URLを取得し、ユーザー認証 – gitコマンド： git clone http://gitlab.example.com/tmiyahar/test.git • ユーザー認証が必要 37
38. 38. Gitのリポジトリ種別 • ローカルリポジトリ – 開発作業用クライアントに作成される – リモートリポジトリをクローンすると作成される • クローンが一番分かりやすい – 他の開発者には影響しない • リモートリポジトリ – GitLab上に作成される – 各開発者で共有される 38
39. 39. ローカルリポジトリの確認 • クローンしたリポジトリを確認 – $ cd ~/test – $ ls -a – 現時点では空っぽです – .gitディレクトリが作られており、リポジトリの各 種情報が格納されている 39
40. 40. リポジトリにファイルを追加 1. 作業ディレクトリにファイルを追加 – $ touch README.md 2. ファイルをステージング – $ git add README.md 3. ステージングしたファイルをコミット – $ git commit 4. コミットしたファイルをリモートにプッシュ – 同時にローカルリポジトリのアップストリーム設定 – $ git push --set-upstream origin master • masterブランチのアップストリームをリモートリポジトリの master（remotes/origin/master）に設定 40
41. 41. リポジトリ操作実行例 $ touch README.md $ git add README.md $ git commit [master f439952] touch test 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md $ git push --set-upstream origin master Counting objects: 3, done. Writing objects: 100% (3/3), 248 bytes | 248.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To http://gitlab.example.com/tmiyahar/test.git 1285f2f..f439952 master -> master Branch master set up to track remote branch master from origin. 41
42. 42. ステージングとコミットの関係 42 作業用 ディレクトリ ステージング 領域 ローカル リポジトリ $ git checkout $ git add $ git commit リポジトリは ブランチ毎の ファイルセットを 保持している
43. 43. リモートリポジトリとの関係 43 ローカル リポジトリ リモート リポジトリ コミット1をプッシュ コミット2をプッシュ コミット3を未プッシュ プル 別の開発者 がプッシュ
44. 44. ブランチを作成する 1. ブランチの確認 – $ git branch – 現時点ではローカルのmasterだけ 2. ブランチの作成 – $ git branch develop 3. ブランチの切り替え（チェックアウト） – $ git checkout develop – $ git checkout –b develop で作成＆移動も 4. ブランチの確認 – $ git branch – 作業しているブランチがdevelopに変更されている 44
45. 45. ブランチ作成実行例 $ git branch * master $ git branch develop $ git checkout develop Switched to branch 'develop' develop branch $ git branch * develop master 45
46. 46. ブランチの流れ 46 master develop $ git branch $ git merge
47. 47. developブランチで作業 1. developブランチのREADME.mdを修正 2. 修正をステージングとコミット – $ git add README.md – $ git commit – $ git commit -a でまとめて実行も可能 3. masterブランチのREADME.mdを確認 – $ git checkout master – $ cat README.md – developブランチでの修正が影響していない事を 確認 47
48. 48. developブランチをマージする 1. developブランチをmasterにマージする – $ git merge develop 2. README.mdを確認 – developブランチで行った修正が反映される • マージは取り込む側のブランチで行う – だから、取り込んで欲しいときは「マージ（プ ル）リクエスト」を作成する 48
49. 49. 超入門の次のステップは？ • 修正の重複（コンフリクト）の解消 – git push時に既にリモートが更新されている – git pullするとコンフリクト発生 – 適切に修正し、再度コミット＆プッシュ 49 developブランチで修正 <<<<<<< HEAD ローカルのmasterブランチで修正 ======= Webブラウザで修正 >>>>>>> fcfafd335fd5d6a4bb8938c1c2dcbe17788debf5
50. 50. ブランチ戦略を考える よくある質問 • Q. 「どのブランチ戦略がいいんですか？」 • A. 「ケースバイケース」 • 考慮すべき事（順不同） – 開発者の人数や規模 – コミットやマージの頻度や粒度 – テストの頻度や方法 – リリースの頻度や方法 50
51. 51. この先に考えたい事 • テスト駆動やチケット駆動との連携 • テストの自動化 – コードコミット→テスト→マージリクエストのサ イクルの自動化 – 粒度が小さいとマージ処理する人が大変 • チケットの自動化 – テスト失敗時に自動的にチケット発行 – テスト成功時に自動的にチケットクローズ 51
52. 52. DevOpSaaSに向けて 52
53. 53. DevOpsの想定される進め方 1. ToBeモデルの構築 2. 現時点での課題の抽出 3. 優先順位の策定 4. PoC環境の構築と運用 5. PoC環境からのフィードバックと改善 6. 小規模社内展開 53 自社だけではスピード感のある DevOps推進は困難
54. 54. DevOpSaaSが解決する課題 標準リファレンスモデル提供によるDevOpsの加速 • 各種ツールの組み合わせテスト済みパッケージの提供 – 標準機能はあらかじめ設定済み • 各種ツールのバージョンアップ追従 – 既存開発・運用環境からの移行支援 • 独自機能の提供 – 可視化ツール、既存ツールのカスタマイズなど • 開発運用担当者の教育・サポート – 標準ドキュメント、教育コースの提供 • サンプルの提供 – 自動化・テストスクリプトのサンプル
55. 55. 提供される主な機能 • チケット管理 • ソースコード管理 • テスト自動化 • デプロイ自動化 • プロジェクトマネジメント • コミュニケーション 55
56. 56. DevOpsトレーニングコース 現在開発中 • 開発：Git/Jenkins/Redmine • 構成自動化：Ansible/Teraform • インフラ：Docker/Rancher/Kubernetis • 運用監視：Prometheus • テスト自動化：Serverspec/Selenium 56
57. 57. 改めて大募集 • 一緒にDevOpsにチャレンジする企業 – 一緒にカイゼンしていきませんか？ • 一緒にDevOpsにチャレンジするエンジニア – 一緒に成長していきませんか？ – 沢山の開発者を支えるお仕事です – マジで人手が足りてません – このままだと掛け声倒れになりかねない 57
58. 58. ありがとうございました 58
59. 59. OSCからのお願い • 休憩時間に少しでもいいので展示会場に 足を運んでください！ • 展示に人が行かないと、OSCに協賛・出展 するメリットが無いと判断されてしまいます • 結果的にOSCが開催できなくなります・・ • 展示会場は2F・5Fにありますよ〜 • ご理解とご協力をよろしくお願いします 59