今さら闻けない人のための驳颈迟超入门 OSC2018京都 資料
Download as PPTX, PDF0 likes422 views
8月3日(金)にOSC2018 京都で行った「今さら闻けない人のための驳颈迟超入门」の資料です。
![リポジトリ操作実行例
$ 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.
31](https://image.slidesharecdn.com/180803git-180803045632/85/git-OSC2018-31-320.jpg)
More Related Content
What's hot (20)
Similar to 今さら闻けない人のための驳颈迟超入门 OSC2018京都 資料 (20)
More from VirtualTech Japan Inc./Begi.net Inc. (20)
今さら闻けない人のための驳颈迟超入门 OSC2018京都 資料
- 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
- 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. 情報サイト：EnterpriseCloud.jp ? OpenStackで始めるエ ンタープライズクラウ ドの情報サイト ? OpenStack導入手順 書のダウンロード ? 各種プレゼン資料 ? その他ブログ記事 5
- 7. 日本仮想化技術株式会社は ? 仮想化技術のエキスパート集団 ? 進取の精神 ? 豊富な検証機材で新技術を追求 ? 自由な雰囲気の職場 7
- 8. 一緒に頑張ってくれる仲間を募集中 ? サーバー、ネットワークエンジニア – 新卒からキャリアアップしたい経験者まで – クラウド技術、自動化技術に興味がある人 ? コンサルタント – 通信系に強い人大歓迎 ? インターン – 学生はもちろん、社会人も可 8
- 12. 充実の福利厚生 ? マッサージチェア ? 充実のフリードリンクコーナー – お茶、ネスプレッソなど多種多様に取り揃え ? 誕生日はケーキでお祝い ? 雑誌年間購読制度 – 何でも好きな雑誌を年間購読 ? 書籍購入支援制度 – 技術書の購入は無制限（当然） – 好きな書籍（漫画も可）を1万円／年購入 12
- 14. 本日のアジェンダ ? DevOpsとは？ ? Gitを利用した開発モデル ? GitLabを使って試してみよう ? GitLabにプロジェクトを作成する ? DevOpSaaSに向けて ? CI/CDを支える中心的な技術であるコード管 理の代表的なGitの使用方法を講師なりに勉 強して仕組みを理解できるように解説します 14
- 15. Gitを利用した開発モデル 15
- 16. Gitを利用したバージョン管理 ? ソースコード等の共有 – 変更履歴を記録、追跡 – 履歴の用途毎に分岐して管理（ブランチ） – 切り戻しが容易 ? プルリクエスト（マージリクエスト）機能によ りレビューを可視化 ? 他のツールとの連携 – Jenkins – Redmine 16
- 17. Gitを利用したバージョン管理 A successful Git branching model http://nvie.com/posts/a-successful-git-branching-model/ – リリース用と開発用の2つのメインブランチを 用意 – 機能追加、バグフィックス等Issue登録を行う毎 にメインブランチから切り出す – 問題が起きても本番用ブランチや他の人の開 発には影響しない – GitLabではマージリクエスト機能によりレ ビューを可視化 17
- 20. デモ環境について 『GitLab実践ガイド』を参考に ? CentOS 7.4にGitLab Community Editionを インストール – Enterprise Editionでもライセンスを有効にしな ければCommunity Edition相当 – Omnibusインストールで必要なものがまとまっ て入ります ? 最新版では未検証 20
- 21. 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 21
- 22. 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 22
- 23. ホスト名の指定と構成変更の適用 ? 以下の条件の場合、インストールの最後で自 動的に構成変更が適当される – ホスト名が正しく設定されている – 逆引きDNSでホスト名を返す ? 【重要】ホスト名を指定して、構成変更の適用 を行う必要がある – /etc/gitlab/gitlab.rbが設定ファイル ? external_url ‘http://gitlab.example.com’ – 設定後再構成を実行 ? sudo gitlab-ctl reconfigure 23 参考
- 25. GitLabの管理単位 ? ユーザー – 各開発者のアカウント ? グループ – ユーザーをまとめた管理単位 ? プロジェクト – ソースコードのリポジトリを含めた開発プロ ジェクトに必要なもの一式 – ユーザー、あるいはグループに紐付けられる 25
- 26. GitLabで初期設定作業 1. http://gitlab.example.comにアクセス 2. ユーザーrootのパスワードを設定 3. ユーザーrootでログイン 4. 新しいユーザーを作成 5. 指定したメールアドレスにメールが届く – http://gitlab.example.comへのリンクが埋め込まれ ている 6. 新規ユーザーのパスワード設定 7. 新規ユーザーでログイン 26
- 27. ユーザーでプロジェクト作成 ユーザーtmiyaharを作成しています 1. 新規プロジェクトtestを作成 2. リポジトリのURLを確認 3. クライアントにリポジトリをクローン – SourceTree：URLを取得し、ユーザー認証 – gitコマンド： git clone http://gitlab.example.com/tmiyahar/test.git ? ユーザー認証が必要 27
- 28. Gitのリポジトリ種別 ? ローカルリポジトリ – 開発作業用クライアントに作成される – リモートリポジトリをクローンすると作成される ? クローンが一番分かりやすい – 他の開発者には影響しない ? リモートリポジトリ – GitLab上に作成される – 各開発者で共有される 28
- 29. ローカルリポジトリの確認 ? クローンしたリポジトリを確認 – $ cd ~/test – $ ls -a – 現時点では空っぽです – .gitディレクトリが作られており、リポジトリの各 種情報が格納されている 29
- 30. リポジトリにファイルを追加 1. 作業ディレクトリにファイルを追加 – $ touch README.md 2. ファイルをステージング – $ git add README.md 3. ステージングしたファイルをコミット – $ git commit 4. コミットしたファイルをリモートにプッシュ – 同時にローカルリポジトリのアップストリーム設定 – $ git push --set-upstream origin master ? masterブランチのアップストリームをリモートリポジトリの master（remotes/origin/master）に設定 30
- 31. リポジトリ操作実行例 $ 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. 31
- 32. ステージングとコミットの関係 32 作業用 ディレクトリ ステージング 領域 ローカル リポジトリ $ git checkout $ git add $ git commit リポジトリは ブランチ毎の ファイルセットを 保持している
- 34. ブランチを作成する 1. ブランチの確認 – $ git branch – 現時点ではローカルのmasterだけ 2. ブランチの作成 – $ git branch develop 3. ブランチの切り替え（チェックアウト） – $ git checkout develop – $ git checkout –b develop で作成＆移動も 4. ブランチの確認 – $ git branch – 作業しているブランチがdevelopに変更されている 34
- 35. ブランチ作成実行例 $ git branch * master $ git branch develop $ git checkout develop Switched to branch 'develop' develop branch $ git branch * develop master 35
- 36. ブランチの流れ 36 master develop $ git branch $ git merge
- 37. 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ブランチでの修正が影響していない事を 確認 37
- 38. developブランチをマージする 1. developブランチをmasterにマージする – $ git merge develop 2. README.mdを確認 – developブランチで行った修正が反映される ? マージは取り込む側のブランチで行う – だから、取り込んで欲しいときは「マージ（プ ル）リクエスト」を作成する 38
- 39. 超入門の次のステップは？ ? 修正の重複（コンフリクト）の解消 – git push時に既にリモートが更新されている – git pullするとコンフリクト発生 – 適切に修正し、再度コミット＆プッシュ 39 developブランチで修正 <<<<<<< HEAD ローカルのmasterブランチで修正 ======= Webブラウザで修正 >>>>>>> fcfafd335fd5d6a4bb8938c1c2dcbe17788debf5
- 40. ブランチ戦略を考える よくある質問 ? Q. 「どのブランチ戦略がいいんですか？」 ? A. 「ケースバイケース」 ? 考慮すべき事（順不同） – 開発者の人数や規模 – コミットやマージの頻度や粒度 – テストの頻度や方法 – リリースの頻度や方法 40
- 41. この先に考えたい事 ? テスト駆動やチケット駆動との連携 ? テストの自動化 – コードコミット→テスト→マージリクエストのサ イクルの自動化 – 粒度が小さいとマージ処理する人が大変 ? チケットの自動化 – テスト失敗時に自動的にチケット発行 – テスト成功時に自動的にチケットクローズ 41
- 42. DevOpSaaSに向けて 42
- 43. DevOpsの想定される進め方 1. ToBeモデルの構築 2. 現時点での課題の抽出 3. 優先順位の策定 4. PoC環境の構築と運用 5. PoC環境からのフィードバックと改善 6. 小規模社内展開 43 自社だけではスピード感のある DevOps推進は困難
- 44. DevOpSaaSが解決する課題 標準リファレンスモデル提供によるDevOpsの加速 ? 各種ツールの組み合わせテスト済みパッケージの提供 – 標準機能はあらかじめ設定済み ? 各種ツールのバージョンアップ追従 – 既存開発?運用環境からの移行支援 ? 独自機能の提供 – 可視化ツール、既存ツールのカスタマイズなど ? 開発運用担当者の教育?サポート – 標準ドキュメント、教育コースの提供 ? サンプルの提供 – 自動化?テストスクリプトのサンプル
- 45. 提供される主な機能 ? チケット管理 ? ソースコード管理 ? テスト自動化 ? デプロイ自動化 ? プロジェクトマネジメント ? コミュニケーション 45
- 46. サポートされる環境 ? 開発：Git/Jenkins/Redmine ? 構成自動化：Ansible ? インフラ：Kubernetis ? 運用監視：Prometheus ? テスト自動化：Serverspec/Selenium 46
- 47. 改めて大募集 ? 一緒にDevOpsにチャレンジする企業 – 一緒にカイゼンしていきませんか？ ? 一緒にDevOpsにチャレンジするエンジニア – 一緒に成長していきませんか？ – 沢山の開発者を支えるお仕事です – マジで人手が足りてません – このままだと掛け声倒れになりかねない 47
- 48. ありがとうございました 48
- 49. OSCからのお願い ? 休憩時間に少しでもいいので展示会場に 足を運んでください！ ? 展示に人が行かないと、OSCに協賛?出展 するメリットが無いと判断されてしまいます ? 結果的にOSCが開催できなくなります?? ? 展示会場は1Fアトリウムにもありますよ? ? ご理解とご協力をよろしくお願いします 49